MODULE 26 - CERTIFICATION REVISION PREPARATION

Question 1

Security Onion Security Onion is an open-source suite of Network Security Monitoring (NSM) tools that run on an Ubuntu Linux distribution.

Answer 1

Security Onion Security Onion is an open-source suite of Network Security Monitoring (NSM) tools that run on an Ubuntu Linux distribution.

Question 2

Security Onion Security Onion tools provide three core functions for the cybersecurity analyst:

full packet capture and data types,

network-based and

host-based intrusion detection systems, and

alert analyst tools.

Answer 2

Security Onion Security Onion tools provide three core functions for the cybersecurity analyst:

full packet capture and data types,

network-based and

host-based intrusion detection systems, and

alert analyst tools.

Question 3

Security Onion Security Onion can be installed as a standalone installation or as a sensor and server platform.

Some components of Security Onion are owned and maintained by corporations, such as Cisco and Riverbend Technologies, but are made available as open source.

Answer 3

Security Onion Security Onion can be installed as a standalone installation or as a sensor and server platform.

Some components of Security Onion are owned and maintained by corporations, such as Cisco and Riverbend Technologies, but are made available as open source.

Question 4

Detection Tools for Collecting Alert Data Security Onion contains many components.

It is an integrated environment which is designed to simplify the deployment of a comprehensive NSM solution.

The figure illustrates a simplified view of the way in which some of the components of the Security Onion work together.

Answer 4

It is an integrated environment which is designed to simplify the deployment of a comprehensive NSM solution.

The figure illustrates a simplified view of the way in which some of the components of the Security Onion work together.

Question 5

Detection Tools for Collecting Alert Data A Security Onion Architecture

https://snipboard.io/41wWVi.jpg

Answer 5

https://snipboard.io/41wWVi.jpg

Question 6

A Security Onion Architecture:

–capME

–SNORT

– ZEEK

– OSSEC

– WAZUH

– SURICATA

Answer 6

–capME

–SNORT

– ZEEK

– OSSEC

– WAZUH

– SURICATA

Question 7

A Security Onion Architecture:

–capME

–SNORT

– ZEEK

– OSSEC

– WAZUH

– SURICATA

Answer 7

– capME

This is a web application that allows viewing of pcap transcripts rendered with the tcpflow or Zeek tools.

CapME can be accessed from the Enterprise Log Search and Archive (ELSA) tool.

CapME provides the cybersecurity analyst with an easy-to-read means of viewing an entire Layer 4 session.

CapME acts as a plugin to ELSA and provides access to relevant pcap files that can be opened in Wireshark.

Question 8

A Security Onion Architecture:

–capME

–SNORT

– ZEEK

– OSSEC

– WAZUH

– SURICATA

Answer 8

– SNORT

This is a Network Intrusion Detection System (NIDS).

It is an important source of alert data that is indexed in the Sguil analysis tool.

Snort uses rules and signatures to generate alerts.

Snort can automatically download new rules using the PulledPork component of Security Onion.

Snort and PulledPork are open source tools that are sponsored by Cisco.

Question 9

A Security Onion Architecture:

–capME

–SNORT

– ZEEK

– OSSEC

– WAZUH

– SURICATA

Answer 9

– ZEEK

Formerly known as Bro.

This is a NIDS that uses more of a behavior-based approach to intrusion detection.

Rather than using signatures or rules, Zeek uses policies, in the form of scripts that determine what data to log and when to issue alert notifications.

Zeek can also submit file attachments for malware analysis, block access to malicious locations, and shut down a computer that appears to be violating security policies.

Note: Some interfaces within Security Onion have yet to be updated with the Bro to Zeek name change.

Question 10

A Security Onion Architecture:

–capME

–SNORT

– ZEEK

– OSSEC

– WAZUH

– SURICATA

Answer 10

– OSSEC

This is a host-based intrusion detection system (HIDS) that is integrated into Security Onion.

It actively monitors host system operations, including conducting file integrity monitoring, local log monitoring, system process monitoring, and rootkit detection.

OSSEC alerts and log data are available to Sguil and Kibana.

OSSEC requires an agent to be running on the Windows computers in the enterprise.

Question 11

A Security Onion Architecture:

–capME

–SNORT

– ZEEK

– OSSEC

– WAZUH

– SURICATA

Answer 11

– WAZUH

Wazuh is a HIDS that will replace OSSEC in Security Onion.

It is a full-featured solution that provides a broad spectrum of endpoint protection mechanisms including host logfile analysis, file integrity monitoring, vulnerability detection, configuration assessment, and incident response.

Like OSSEC, it requires agents to be running on network hosts.

Question 12

A Security Onion Architecture:

–capME

–SNORT

– ZEEK

– OSSEC

– WAZUH

– SURICATA

Answer 12

– SURICATA

This is a NIDS that uses a signature-based approach.

It can also be used for inline intrusion prevention.

It is similar to Zeek; however, Suricata uses native multithreading, which allows the distribution of packet stream processing across multiple processor cores.

It also includes some additional features such as reputation-based blocking and support for Graphics Processing Unit (GPU) multithreading for performance improvement.

Question 13

Analysis Tools Security Onion integrates these various types of data and Intrusion Detection System (IDS) logs into a single platform through the following tools:

– Sguil

– Kibana

– Wireshark

– Zeek

Answer 13

Analysis Tools Security Onion integrates these various types of data and Intrusion Detection System (IDS) logs into a single platform through the following tools:

– Sguil

– Kibana

– Wireshark

– Zeek

Question 14

Analysis Tools:

Analysis Tools Security Onion integrates these various types of data and Intrusion Detection System (IDS) logs into a single platform through the following tools:

– Sguil

– Kibana

– Wireshark

– Zeek

Answer 14

– Sguil

This provides a high-level console for investigating security alerts from a wide variety of sources.

Sguil serves as a starting point in the investigation of security alerts.

A wide variety of data sources are available to the cybersecurity analyst by pivoting directly from Sguil to other tools.

Question 15

Analysis Tools :

Analysis Tools Security Onion integrates these various types of data and Intrusion Detection System (IDS) logs into a single platform through the following tools:

– Sguil

– Kibana

– Wireshark

– Zeek

Answer 15

– Kibana

Kibana is an interactive dashboard interface to Elasticsearch data.

It allows querying of NSM data and provides flexible visualizations of that data.

It provides data exploration and machine learning data analysis features.

It is possible to pivot from Sguil directly into Kibana to see contextualized displays based on the source and destination IP addresses that are associated with an alert.

Search the internet and visit the elastic.co website to learn more about the many features of Kibana.

Question 16

Analysis Tools :

Analysis Tools :

Analysis Tools Security Onion integrates these various types of data and Intrusion Detection System (IDS) logs into a single platform through the following tools:

– Sguil

– Kibana

– Wireshark

– Zeek

Answer 16

– Wireshark

This is a packet capture application that is integrated into the Security Onion suite.

It can be opened directly from other tools and will display full packet captures relevant to an analysis.

Question 17

Analysis Tools :

Analysis Tools :

Analysis Tools :

Analysis Tools Security Onion integrates these various types of data and Intrusion Detection System (IDS) logs into a single platform through the following tools:

– Sguil

– Kibana

– Wireshark

– Zeek

Answer 17

– Zeek

This is a network traffic analyzer that serves as a security monitor.

Zeek inspects all traffic on a network segment and enables in-depth analysis of that data.

Pivoting from Sguil into Zeek provides access to very accurate transaction logs, file content, and customized output.

Question 18

Alert Generation Security alerts are notification messages that are generated by NSM tools, systems, and security devices.

Alerts can come in many forms depending on the source.

For example, syslog provides support for severity ratings which can be used to alert cybersecurity analysts regarding events that require attention.

Answer 18

Alert Generation Security alerts are notification messages that are generated by NSM tools, systems, and security devices.

Alerts can come in many forms depending on the source.

For example, syslog provides support for severity ratings which can be used to alert cybersecurity analysts regarding events that require attention.

Question 19

Alert Generation In Security Onion

Sguil provides a console that integrates alerts from multiple sources into a timestamped queue.

A cybersecurity analyst can work through the security queue investigating, classifying, escalating, or retiring alerts.

Answer 19

Sguil provides a console that integrates alerts from multiple sources into a timestamped queue.

A cybersecurity analyst can work through the security queue investigating, classifying, escalating, or retiring alerts.

Question 20

Alert Generation Instead of using a dedicated workflow management system such as Request Tracker for Incident Response (RTIR), a cybersecurity analyst would use the output of an application like Sguil to orchestrate an NSM investigation.

Answer 20

Alert Generation Instead of using a dedicated workflow management system such as Request Tracker for Incident Response (RTIR), a cybersecurity analyst would use the output of an application like Sguil to orchestrate an NSM investigation.

Question 21

Alert Generation Alerts will generally include five-tuples information when available, as well as timestamps and information identifying which device or system generated the alert.

Recall that the five-tuples includes the following information for tracking a conversation between a source and destination application:

Answer 21

Alert Generation Alerts will generally include five-tuples information when available, as well as timestamps and information identifying which device or system generated the alert.

Recall that the five-tuples includes the following information for tracking a conversation between a source and destination application:

Question 22

Alert Generation Recall that the five-tuples includes the following information for tracking a conversation between a source and destination application:

SrcIP - the source IP address for the event.

SPort - the source (local) Layer 4 port for the event.

DstIP - the destination IP for the event.

DPort - the destination Layer 4 port for the event.

Pr - the IP protocol number for the event.

Answer 22

Alert Generation Recall that the five-tuples includes the following information for tracking a conversation between a source and destination application:

SrcIP - the source IP address for the event.

SPort - the source (local) Layer 4 port for the event.

DstIP - the destination IP for the event.

DPort - the destination Layer 4 port for the event.

Pr - the IP protocol number for the event.

Question 23

Alert Generation

Additional information could be whether a permit or deny decision was applied to the traffic, some captured data from the packet payload, or a hash value for a downloaded file, or any of a variety of data.

Answer 23

Alert Generation

Additional information could be whether a permit or deny decision was applied to the traffic, some captured data from the packet payload, or a hash value for a downloaded file, or any of a variety of data.

Question 24

Alert Generation

The figure shows the Sguil application window with the queue of alerts that are waiting to be investigated in the top portion of the interface.

Sguil Window

https://snipboard.io/rVPHYb.jpg

Answer 24

Alert Generation

The figure shows the Sguil application window with the queue of alerts that are waiting to be investigated in the top portion of the interface.

Sguil Window

https://snipboard.io/rVPHYb.jpg

Question 25

Alert Generation:

The fields available for the real-time events are as follows:

– ST

– CNT

– Sensor

– Alert ID

– Date/Time

– Event Message

Answer 25

Alert Generation:

The fields available for the real-time events are as follows:

– ST

– CNT

– Sensor

– Alert ID

– Date/Time

– Event Message

Question 26

Alert Generation:

The fields available for the real-time events : ST

Alert Generation:

The fields available for the real-time events are as follows:

– ST

– CNT

– Sensor

– Alert ID

– Date/Time

– Event Message

Answer 26

–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.

Question 27

Alert Generation:

The fields available for the real-time events :

The fields available for the real-time events are as follows:

– ST

– CNT

– Sensor

– Alert ID

– Date/Time

– Event Message

Answer 27

• 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.

Question 28

Alert Generation: The fields available for the real-time events :

The fields available for the real-time events are as follows:

– ST

– CNT

– Sensor

– Alert ID

– Date/Time

– Event Message

Answer 28

– 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.

Question 29

Alert Generation: The fields available for the real-time events : Alert ID

The fields available for the real-time events are as follows:

– ST

– CNT

– Sensor

– Alert ID

– Date/Time

– Event Message

Answer 29

– 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.

Question 30

Alert Generation: The fields available for the real-time events : Date/Time

The fields available for the real-time events are as follows:

– ST

– CNT

– Sensor

– Alert ID

– Date/Time

– Event Message

Answer 30

– Date/Time

This is the timestamp for the event.

In the case of correlated events, it is the timestamp for the first event.

Question 31

Alert Generation: The fields available for the real-time events : Event Message

The fields available for the real-time events are as follows:

– ST

– CNT

– Sensor

– Alert ID

– Date/Time

– Event Message

Answer 31

– 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.

Question 32

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 32

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.

Question 33

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 33

Rules and Alerts Alerts can come from a number of sources:

NIDS

HIDS

Asset management and monitoring

HTTP, DNS, and TCP transactions

Syslog messages

Question 34

Rules and Alerts Alerts can come from a number of sources: NIDS

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 34

– NIDS

Snort, Zeek, and Suricata

Question 35

Rules and Alerts Alerts can come from a number of sources: HIDS

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 35

– HIDS

OSSEC, Wazuh

Question 36

Rules and Alerts Alerts can come from a number of sources: Asset management and monitoring

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 36

– Assest Management and Monitoring

Passive Asset Detection System (PADS)

Question 37

Rules and Alerts Alerts can come from a number of sources:

HTTP, DNS, and TCP transactions

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 37

– HTTP, DNS, and TCP transcations

Recorded by Zeek and pcaps

Question 38

Rules and Alerts Alerts can come from a number of sources:

Syslog messages

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 38

– Syslog messages

Multiple sources

Question 39

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 39

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.

Question 40

Rules and Alerts

The Sguil alert in the figure was triggered by a rule that was configured in Snort.

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 40

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.

Question 41

Rules and Alerts Sguil Alert and the Associated Rule

https://snipboard.io/ZeA4ki.jpg

Answer 41

Rules and Alerts Sguil Alert and the Associated Rule

https://snipboard.io/ZeA4ki.jpg

Question 42

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

Answer 42

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

Question 43

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 43

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

Question 44

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 44

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

Question 45

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 45

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

Question 46

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 46

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.

Question 47

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 47

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.

Question 48

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 48

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.

Question 49

Snort Rule Structure Snort Rule Header Structure

Snort Rule Header Structure

https://snipboard.io/UfKNGE.jpg

Answer 49

Snort Rule Structure Snort Rule Header Structure

Snort Rule Header Structure

https://snipboard.io/UfKNGE.jpg

Question 50

Snort Rule Structure Snort Rule Header Structure

COMPONENTS: alert ip any any -> any any

Answer 50

Snort Rule Structure Snort Rule Header Structure

COMPONENTS: alert ip any any -> any any

Question 51

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 51

Snort Rule Structure Snort Rule Header Structure : alert

the action to be taken is to issue an alert, other actions are log and pass

Question 52

Snort Rule Structure Snort Rule Header Structure : ip

the protocol

Answer 52

Snort Rule Structure Snort Rule Header Structure : ip

the protocol

Question 53

Snort Rule Structure Snort Rule Header Structure :any any

the specified source is any IP address and any Layer 4 port

Answer 53

Snort Rule Structure Snort Rule Header Structure :any any

the specified source is any IP address and any Layer 4 port

Question 54

Snort Rule Structure Snort Rule Header Structure : ->

the direction of flow is from the source to the destination

Answer 54

Snort Rule Structure Snort Rule Header Structure : ->

the direction of flow is from the source to the destination

Question 55

Snort Rule Structure Snort Rule Header Structure : any any

the specified destination is any IP address and any Layer 4 port

Answer 55

Snort Rule Structure Snort Rule Header Structure : any any

the specified destination is any IP address and any Layer 4 port

Question 56

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 56

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.

Question 57

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 57

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.

Question 58

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 58

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

Question 59

Snort rule messages may include the source of the rule. Three common sources for Snort rules are: GPL

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 59

–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.

Question 60

Three common sources for Snort rules are: ET

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 60

– 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.

Question 61

Three common sources for Snort rules are:

VRT

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 61

– 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.

Question 62

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 62

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

Question 63

Snort Rule Structure Component :

msg:

Text that describes the alert.

Answer 63

Snort Rule Structure Component :

msg:

Text that describes the alert.

Question 64

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 64

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.

Question 65

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 65

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.

Question 66

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 66

Snort Rule Structure Component : classtype:

A category for the attack.

Snort includes a set of default categories that have one of four priority values.

Question 67

Snort Rule Structure Component : sid:

A unique numeric identifier for the rule.

Answer 67

Snort Rule Structure Component : sid:

A unique numeric identifier for the rule.

Question 68

Snort Rule Structure Component : rev:

The revision of the rule that is represented by the sid.

Answer 68

Snort Rule Structure Component : rev:

The revision of the rule that is represented by the sid.

Question 69

The Need for Alert Evaluation

The threat landscape is constantly changing as new vulnerabilities are discovered and new threats evolve.

Answer 69

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.

Question 70

The Need for Alert Evaluation

It is impossible to design measures to prevent all exploits.

Answer 70

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.

Question 71

The Need for Alert Evaluation

Detection rules should be overly conservative.

Answer 71

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.

Question 72

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 72

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

Question 73

Evaluating Alerts Security incidents are classified using a scheme borrowed from medical diagnostics.

Answer 73

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.

Question 74

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 74

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.

Question 75

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 75

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?”

Question 76

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 76

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.

Question 77

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 77

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.

Question 78

Evaluating Alerts

When an alert is issued, it will receive one of four possible classifications

https://snipboard.io/W4Zbcv.jpg

Answer 78

Evaluating Alerts

When an alert is issued, it will receive one of four possible classifications

https://snipboard.io/W4Zbcv.jpg

Question 79

Evaluating Alerts

True positives are the desired type of alert.

They mean that the rules that generate alerts have worked correctly.

Answer 79

Evaluating Alerts True positives are the desired type of alert.

They mean that the rules that generate alerts have worked correctly.

Question 80

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 80

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.

Question 81

Evaluating Alerts

True negatives are desirable.

They indicate that benign normal traffic is correctly ignored, and erroneous alerts are not being issued.

Answer 81

Evaluating Alerts

True negatives are desirable.

They indicate that benign normal traffic is correctly ignored, and erroneous alerts are not being issued.

Question 82

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 82

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.

Question 83

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 83

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.

Question 84

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 84

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.

Question 85

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 85

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.

Question 86

Evaluating Alerts

False negatives may be discovered well after an exploit has occurred.

This can happen through retrospective security analysis (RSA).

RSA can occur when newly obtained rules or other threat intelligence is applied to archived network security data.

Answer 86

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.

Question 87

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 87

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.

Question 88

Deterministic Analysis and Probabilistic Analysis

Two general approaches used to do this are deterministic and probabilistic analysis.

Deterministic analysis evaluates risk based on what is known about a vulnerability.

It assumes that for an exploit to be successful all prior steps in the exploit process must also be successful.

Answer 88

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.

Question 89

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 89

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.

Question 90

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 90

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.

Question 91

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 91

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.

Question 92

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.

Answer 92

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.