Module 4: Network traffic and logs using IDS and SIEM tools

History books. Receipts. Diaries. What do all these things have in common? They record events. Whether it’s
historical events, financial transactions, or private diary entries, records preserve event details. And having access to these details
can help us in many ways. Previously, we explored
the different types of processes and procedures involved during each phase
of the incident response lifecycle. In this section, we’ll direct our focus
on one of the key components of incident investigation, logs and alerts. In security, logs record event details and these details are used to
support investigations. First, you’ll learn all about logs,
what they are, and how they’re created. You’ll also learn how to read and
analyze logs. Then, we’ll revisit intrusion
detection systems. You’ll explore how to
interpret signatures. You’ll have an opportunity to apply what
you’ve learned through hands-on activities using a tool called Suricata. Finally, you’ll search in
SIEM tools like Splunk and Chronicle to locate events of interest and
access log data. Events are a valuable data source. They help create context
around an alert, so you can interpret the actions
that took place on a system. Knowing how to read, analyze, and
connect different events will help you identify malicious behavior and
protect systems from attack. Ready?
Let’s begin.

Introduction:

Imagine you’re a detective investigating a crime scene. To piece together the story, you rely on clues like fingerprints, witness statements, and security camera footage. Similarly, in the digital world, logs play a crucial role in cybersecurity investigations.

What are logs?

Logs are like electronic diaries, recording events happening within your systems. They provide detailed information about actions, users, timestamps, and more. Think of them as breadcrumbs left behind by every digital activity, helping you track user actions and potential security incidents.

Why are logs important?

• Detection: Logs act as early warning signs. Unusual activities, suspicious login attempts, or malware execution attempts all leave traces in logs, allowing you to detect potential threats before they cause damage.
• Investigation: When an incident occurs, logs are your go-to evidence. They help you build a timeline of events, identify the source of the attack, and understand how the attacker moved through your systems.
• Compliance: Many regulations require organizations to maintain logs for a specific period. This helps demonstrate due diligence and provides evidence in case of audits or legal proceedings.
• Troubleshooting: Beyond security, logs can help diagnose system performance issues, identify resource bottlenecks, and track user activity for troubleshooting purposes.

Types of logs:

• System logs: Record events within operating systems, applications, and services.
• Network logs: Track network traffic, including source and destination IPs, protocols, and port numbers.
• Security logs: Capture events related to security tools like firewalls, intrusion detection systems, and antivirus software.
• Application logs: Specific to software applications, recording user actions, errors, and other events.

Effective log management:

• Collect from all sources: Ensure you gather logs from all devices and systems within your network.
• Centralize storage: Store logs in a central repository for efficient access and analysis.
• Standardize format: Convert logs to a common format for easier search and analysis across different sources.
• Monitor and analyze: Regularly review logs for suspicious activity and potential threats.
• Retain logs: Keep logs for a defined period based on compliance requirements and investigation needs.

Tools for log management:

• SIEM (Security Information and Event Management) tools: Aggregate and analyze logs from various sources in real-time.
• Log analysis platforms: Offer advanced search capabilities, visualizations, and threat detection features.
• Open-source logging tools: Free and powerful options for smaller organizations or specific needs.

Conclusion:

Logs are invaluable tools for security professionals. By understanding their importance, implementing effective log management practices, and leveraging the right tools, you can turn this digital breadcrumbs into actionable insights, enhancing your overall cybersecurity posture. Remember, strong logs can mean a stronger defense against cyber threats.

Additional tips:

• Conduct regular log analysis drills to practice incident response.
• Implement log tamper prevention measures to ensure log integrity.
• Stay updated on emerging threats and adapt your log analysis to identify new patterns.

By actively utilizing logs, you can transform your cybersecurity defense from reactive to proactive, ensuring your systems and data remain safe in the ever-evolving digital landscape.

Devices produced data
in the form of events. As a refresher, events are observable
occurrences that happen on a network system or device. This data provides visibility
into an environment. Logs are one of the key ways security
professionals detect unusual or malicious activity. A log is a record of events that
occur within an organization’s systems. System activity is recorded in
what’s known as a log file or commonly called logs. Almost every device or
system can generate logs. Logs contain multiple entries which detail
information about a specific event or occurrence. Logs are useful to security analysts
during incident investigation since they record details of what, where, and
when an event occurred on the network. This includes details like date, time,
location, the action made, and the names of the users or
systems who performed the action. These details offer valuable insight,
not only for troubleshooting issues related
to system performance, but most importantly, for
security monitoring. Logs allow analysts to build a story and timeline around various event occurrences
to understand what exactly happened. This is done through log analysis. Log analysis is the process of examining
logs to identify events of interest. Since there are different
sources available to get logs, an enormous volume of log
data can be generated. It’s helpful to be selective in what
we log, so that we can log efficiently. For example, web applications generate
a high volume of log messages, but not all of this data may be
relevant to an investigation. In fact, it may even slow things down. Excluding specific data from being logged helps reduce the time spent
searching through log data. You may recall our discussion
on SIEM technology. SIEM tools provide security professionals
with a high-level overview of what happens in a network. SIEM tools do this by first collecting
data from multiple data sources. Then, the data gets aggregated or
centralized in one place. Finally, the diverse log
formats get normalized or converted into a single preferred format. SIEM tools help process large log volumes
from multiple data sources in real-time. This allows security analysts to
quickly search for log data and perform log analysis to
support their investigations. So how do logs get collected? Software known as log forwarders
collect logs from various sources and automatically forward them to
a centralized log repository for storage. Since different types of devices and
systems can create logs, there are different log data
sources in an environment. These include network logs, which
are generated by devices such as proxies, routers, switches, and firewalls, and system logs, which are generated
by operating systems. There’s also application logs, which
are logs related to software applications, security logs, which are generated
by security tools like IDS or IPS, and lastly authentication logs,
which record login attempts. Here’s an example of
a network log from a router. There are a couple of log entries here, but
we’ll focus on the first line. Here, we can observe a number of fields. First, there’s an action specifying
ALLOW. This means that the router’s firewall settings allowed access from
a specific IP address to google.com. Next, there’s a field specifying
the source, which lists an IP address. So far, the information from this log entry
is telling us that network traffic to google.com from this source
IP address is allowed. The last field specifies the timestamp, which is one of the most
essential fields in a log. We can identify the exact date and
time of an action that’s occurred. This is useful for correlating multiple events to develop
a timeline of the incident. There you have it! You’ve analyzed your
first network log. Coming up, we’ll continue our discussion on logs and
explore log formats.

[MUSIC] I am Rebecca,
I’m a security engineer at Google, and I focus in identity management. The best part of the job is
probably thinking like an attacker. I love that part of seeing how can
I break stuff, seeing a system and figuring out how can I get into it. If I was a bad guy,
what would I be wanting? What would I be looking for? How would I find the credentials? How would I find the machine
that’s useful, and get onto it? My first day in security,
we were learning a new tool. The whole organization was in a training,
and they’re like, we’re going to throw you in. It’s a one week training to
learn a network analyzer. I didn’t know anything about networks, let alone network security, or
what this thing was going to be used for. And so I was very overwhelmed, because
I felt like I was an imposter sitting in somebody’s seat who
should belong there. And learning stuff way over my head. I pushed through it by asking a lot of
questions, and setting aside that feeling like I should know things, because I’ve
never been exposed to it at that point. The only way I’m going to
know is if I ask. So, this course has a lot of tools,
and covers a lot of information. And it can be very easy to be overwhelmed,
in fact, I probably would be as well. There’s a lot of information
that you can take in. I think of learning in a course like this,
where there’s a series of courses for you to learn,
that it’s like climbing a mountain. You’ve gotten so far up the mountain,
and the air gets thin, and, yes, it is difficult. You feel overwhelmed, but
you’re almost to the top. And know that when you get to the top, you’re going to have
an amazing view of the world. And that’s the same thing of
when you finish these courses. Your frame of mind and
how you view things and your capabilities, your potential for finding new jobs, or
changing careers is that much better.

Tutorial: Variations of Logs in Cybersecurity

Introduction

In the world of cybersecurity, logs are like digital footprints, recording events and activities that occur within systems and networks. They provide invaluable insights for security analysts, enabling them to detect anomalies, investigate incidents, and track user behavior. However, logs come in a wide variety of formats, each with its own structure and characteristics. Understanding these variations is essential for effective log analysis and interpretation.

Common Log Formats

1. Syslog:
   • One of the most widely used log formats.
   • Employs a header, structured data, and message format.
   • Example: Feb 25 15:33:11 hostname app[12345]: This is a log entry!
   • Syslog log format example: https://www.golinuxhub.com/2014/01/syslog-tutorial/
2. JSON (JavaScript Object Notation):
   • Human-readable, text-based format using key-value pairs.
   • Lightweight and easy to parse.
   • Example: JSON{ "Alert": "Malware", "Timestamp": "2024-01-02T10:45:30Z", "Source": "Endpoint123" }
   • JSON log format example: https://en.wikipedia.org/wiki/JSON
3. XML (Extensible Markup Language):
   • Structured format using tags and elements.
   • Flexible for representing complex data.
   • Example: XML<?xml version="1.0"?> <log> <event> <timestamp>2024-01-02T14:22:15Z</timestamp> <user>john.smith</user> <action>File access</action> </event> </log>
   • XML log format example: https://docs.stackify.com/docs/troubleshoot-errors-and-logs-net-configurations
4. CSV (Comma-Separated Values):
   • Simple format using commas to separate values.
   • Easy to generate and process.
   • Example: Timestamp,User,Action,File 2024-01-02 15:05:00,jane.doe,Login, 2024-01-02 15:10:12,john.smith,File access,report.pdf
   • CSV log format example: https://docs.panther.com/data-onboarding/custom-log-types/example-csv

Other Log Formats:

• Windows Event Logs: Log events from the Windows operating system.
• Apache Logs: Record web server activity.
• Firewall Logs: Track network traffic and access attempts.
• Application-Specific Logs: Generated by specific software applications.

Factors to Consider When Choosing a Log Format

• Readability: How easy is it for humans to understand the format?
• Parsability: How easy is it for machines to process the format?
• Structure: How well-organized is the data within the format?
• Standardization: Is the format widely used and supported by tools?

Effective Log Analysis

• Centralize log collection: Gather logs from various sources into a central repository.
• Normalize log formats: Convert logs into a common format for easier analysis.
• Filter and correlate events: Focus on relevant events and identify patterns.
• Visualize log data: Use tools to create charts and graphs for better understanding.
• Automate analysis tasks: Use scripts and tools to streamline analysis processes.

Conclusion

Understanding the variations of logs is a crucial skill for cybersecurity professionals. By mastering different log formats, you’ll be able to extract valuable insights, detect threats, and investigate incidents more effectively, ultimately contributing to the overall security posture of your organization.

When you purchase
an item in a store, you usually receive a receipt
as a record of purchase. The receipt breaks down the transaction information with details such as
the date and time, the cashier’s name,
the item name, cost, and the method of payment. But, not all store
receipts look the same. For example, receipts like
automotive invoices use lots of detail when listing the items or services
that were sold. You most likely won’t find this much detail from
a restaurant receipt. Despite the differences
among store receipts, all receipts contain
important details that are relevant
to the transaction. Logs are similar to receipts. While receipts record purchases, logs record the events or activities that happen
on a network or system. As a security analyst, you’ll be responsible
for interpreting logs. Logs come in different formats, so not all logs look the same. But, they usually contain
information like timestamps, system characteristics,
like IP addresses, and a description of
the event, including the action taken and who
performed the action. We know that logs can
be generated from many different data sources
such as network devices, operating systems, and more. These log sources generate
logs in different formats. Some log formats
are designed to be human-readable while others
are machine-readable. Some logs can be verbose, which means they contain
lots of information, while some are short and simple. Let’s explore some
commonly used log formats. One of the most commonly
used log formats is Syslog. Syslog is both a protocol
and a log format. As a protocol, it
transports and writes logs. As a log format, it
contains a header, followed by structured-data,
and a message. The Syslog entry includes
three sections: a header, structured-data,
and a message. The header contains data
fields like Timestamp, the Hostname, the
Application name, and the Message ID. The structured-data
portion contains additional data information
in key-value pairs. Here, the eventSource
is a key that specifies the data
source of the log, which is the value Application. Lastly, the message
component contains the detailed log message
about the event. In this example, “This is a
log entry!” is the message. Let’s explore another
common log format you might encounter as
a security analyst. JavaScript Object Notation,
more popularly known as JSON, is a text-based format designed to be easy
to read and write. It also uses key-value
pairs to structure data. Here’s an example of a JSON log. The curly brackets represent the beginning and
end of an object. The object is the data that’s enclosed between the brackets. It’s organized using
key-value pairs where each key has a corresponding
value separated by colons. For example, for the first line, the key is Alert and
the value is Malware. JSON is known for its simplicity
and easy readability. As a security analyst, you’ll use JSON to read
and write data like logs. eXtensible Markup
Language, or XML, is a language and a format used for storing and
transmitting data. Instead of key-value pairs, it uses tags and other
keys to structure data. Here, we have an example of an XML log entry
with four fields: firstName, lastName, employeeID, and dateJoined, which are separated with arrows. Finally, Comma Separated
Values, or CSV, is a format that
uses separators like commas to separate data values. In this example, there are many different data fields which are separated with commas. Now that you know about the
diversity of log formats, you can focus on evaluating logs to build context
around a detection. Coming up, you’ll explore how IDS signatures are
used to detect, log, and alert on
suspicious activity.

Securing your systems and networks against ever-evolving threats requires constant vigilance. This is where security monitoring comes into play. By implementing detection tools and techniques, you gain the ability to proactively identify suspicious activity and respond to incidents before they cause significant damage.

This tutorial will serve as your roadmap to understanding and implementing security monitoring with detection tools. We’ll delve into the fundamentals, explore different types of tools, and equip you with the knowledge to build a robust security posture.

1. Understanding the Landscape:

Before diving into tools, let’s establish a common ground.

• Data is king: Effective detection relies heavily on data collected from various sources like logs, network traffic, and endpoint activity. Understanding how these data points are generated and collected is crucial.
• Telemetry vs. Logs: Telemetry refers to the ongoing collection and transmission of data, while logs capture specific events that have occurred. Both are valuable sources of information for security monitoring.

2. Introducing the Watchdogs:

Now, let’s meet the key players in security monitoring:

• Intrusion Detection Systems (IDS): These systems continuously monitor activity for suspicious patterns and generate alerts. They come in two flavors:
  • Host-based IDS: Monitors a single device for malicious activity.
  • Network-based IDS: Monitors network traffic for suspicious patterns.
• Security Information and Event Management (SIEM): A central hub that collects, analyzes, and correlates data from various security tools, including IDS and logs, providing a holistic view of your security posture.

3. Decoding the Threats:

Detection tools rely on various techniques to identify suspicious activity, including:

• Signature-based detection: Matches monitored activity against predefined patterns of known threats.
• Anomaly-based detection: Identifies activity that deviates from established baselines of normal behavior.
• Behavioral analysis: Monitors user and system behavior for suspicious patterns, such as unusual login attempts or data exfiltration.

4. Building Your Arsenal:

Now that you understand the basics, let’s explore some popular tools you can leverage:

• Open-source IDS: Snort, Suricata, and Zeek are powerful open-source options for network-based intrusion detection.
• Commercial IDS: Security vendors like Palo Alto Networks, MacAfee, and Cisco offer comprehensive IDS solutions with advanced features.
• SIEM platforms: Splunk, Elastic SIEM, and LogRhythm are leading SIEM platforms that provide centralized log management and analysis capabilities.

5. Putting it all Together:

Implementing security monitoring is an ongoing process. Here’s a roadmap to get you started:

• Define your goals: What are you trying to achieve with security monitoring? Identify your critical assets and prioritize threats accordingly.
• Select your tools: Choose tools that align with your needs, budget, and technical expertise.
• Configure and deploy: Set up your chosen tools and configure them to monitor relevant data sources.
• Refine and adapt: Regularly analyze alerts, refine your detection rules, and adapt your monitoring strategy as threats evolve.

Remember: Security monitoring is not a one-time fix. It’s a continuous process that requires dedication, expertise, and adaptation. By understanding the fundamentals, choosing the right tools, and constantly refining your approach, you can build a robust security posture that effectively safeguards your systems and networks.

This is just a starting point. As you delve deeper, you’ll discover a vast array of tools, techniques, and best practices to explore. Remember, the key is to stay informed, adapt to the changing threat landscape, and continuously improve your security posture.

Feel free to ask any questions you have along the way. Happy monitoring!

When monitoring activity, what specifies the rules used by an intrusion detection system (IDS)?

A signature

A signature specifies the rules that an IDS uses to monitor activity. Signature analysis is one of the most common methods of detection used by IDS tools.

Detection requires data, and this data can come from
various data sources. You’ve already explored how different devices produce logs. Now we’ll examine how different
detection technologies monitor devices and log different types
of system activity, like network and
endpoint telemetry. Telemetry is the collection and transmission of
data for analysis. While logs record events
occurring on systems, telemetry describes
the data itself. For example, packet captures are considered
network telemetry. For security professionals, logs and telemetry
are sources of evidence that can be used to answer questions
during investigations. Previously, you learned about an intrusion detection
system, or IDS. Remember that IDS is
an application that monitors activity and alerts
on possible intrusions. This includes monitoring
different parts of a system or network
like an endpoint. An endpoint is any device connected on a network,
such as a laptop, tablet, desktop computer,
or a smartphone. Endpoints are entry points into a network, which makes
them key targets for malicious actors
looking to gain unauthorized access
into a system. To monitor endpoints
for threats or attacks, a host-based intrusion
detection system can be used. It’s an application
that monitors the activity of the host
on which it’s installed. To clarify, a host
is any device that communicates with other
devices on a network, similar to an endpoint. Host-based intrusion
detection systems are installed as an
agent on a single host, such as a laptop
computer or a server. Depending on its configuration, host-based intrusion
detection systems will monitor the host on which it’s installed to
detect suspicious activity. Once something has
been detected, it records output as logs
and an alert gets generated. What if we wanted to
monitor a network? A network-based intrusion
detection system collects and analyzes network
traffic and network data. Network-based intrusion
detection systems work similar to packet sniffers because they analyze
network traffic and network data on a specific
point in the network. It’s common to deploy
multiple IDS sensors at different points in the network to achieve adequate visibility. When suspicious or unusual
network activity is detected, the network-based
intrusion detection system logs it and generates an alert. In this example, the network-based intrusion
detection system is monitoring the traffic
that’s both coming from and going to the internet. Intrusion detection systems use different types of
detection methods. One of the most common methods
is signature analysis. Signature analysis is
a detection method used to find events
of interest. A signature specifies
a set of rules that an IDS refers to when it
monitors activity. If the activity matches the
rules in the signature, the IDS logs it and
sends out an alert. For example, a signature can be written to generate an alert if a failed login on a system
happens three times in a row, which suggests a possible
password attack. Before alerts are generated, the activity must be logged. IDS technologies record the
information of the devices, systems, and networks which
they monitor as IDS logs. IDS logs can then
be sent, stored, and analyzed in a centralized
log repository like a SIEM. Coming up, we’ll
explore how to read and configure signatures.
Meet you there!

[MUSIC] Hi, I’m Grace, and I work in Detection and
Response at Google. When I tell people what I do,
they think it’s awesome, I love being able to say, my job is to
detect hackers trying to hack Google. There are people who trust us with their
data that play critical roles in society, like journalists and
activists, for example. So they need to be able to
have their data with us and trust that it’s going to be safe. Security mindset is about curiosity. There’s a really nice overlap between
cybersecurity and computers and having that creative and logical outlet
and an interest in big world matters. What hackers are thinking,
what defenders are thinking. I’m empathizing with people
looking at how information can be attained,
perhaps sometimes from unusual sources. An example of one of the craziest things
that I’ve learned about would be how people can get information from a CPU. Some tasks for
a CPU are more difficult than others, require more energy to do multiplying
numbers as an example of that, which means that the CPU
is going to work harder, it’s going to get hotter,
it’s going to be executing more functions. So you can use that information to know
things about what that CPU is doing. From there, you can start to deduce what’s
happening at a given point in time. What I recommend to people who
are interested in developing a security mindset is listen to stories. There are podcasts that have
great interviews with hackers. I recommend following the news and
reading news articles about different cyber threats that
are happening on in the world. I recommend going to conferences,
go to meetups, finding people that you can study with and
practice with. Even hackers are teaching each other how
to hack things in forums and chat rooms. It’s not cheating to ask for help. Another piece of advice that I have for people would be to not give
up when you have roadblocks. Studying the certificate
is a really good idea, and it’s really worth persevering
right to the very end. Even when it gets hard and you start
feeling overwhelmed, that’s okay, they’re new terms. I can guarantee that if you come back
to it later, you’ll be more familiar. You’ll find it easier. Being really gentle with yourself and
understanding and patient will help a lot when
you’re facing these challenges. [SOUND]

Introduction

In the realm of cybersecurity, detection signatures play a pivotal role in identifying and flagging suspicious activity within networks and systems. They act as blueprints that guide security tools in recognizing potential threats. Understanding the components of a detection signature is crucial for effectively configuring and utilizing these tools. This tutorial will delve into the key elements of signatures and how they work together to safeguard your digital assets.

Key Components

1. Action:

• Determines the action to be taken when a rule is triggered.
• Common actions include:
  • Alert: Generate a notification to security personnel.
  • Log: Record the event for further analysis.
  • Block: Prevent the suspicious traffic from proceeding.

2. Header:

• Defines the specific characteristics of the network traffic to be scrutinized.
• Typically includes:
  • Protocol: The communication language used (e.g., TCP, UDP, ICMP).
  • IP Addresses: Source and destination IP addresses.
  • Ports: Specific communication channels.
  • Direction: Incoming or outgoing traffic.

3. Rule Options:

• Offer customization and fine-tuning of the signature’s detection capabilities.
• Examples include:
  • Content Matching: Seeking specific patterns within network packets (e.g., malicious code).
  • Time Constraints: Activating or deactivating rules based on time frames.
  • Message: Customizing the alert message to provide relevant details.

4. Meta-Information:

• Provides additional context for signature identification and management.
• Examples include:
  • Signature ID (SID): Unique identifier for each signature.
  • Revision Number: Indicates updates or modifications to the signature.
  • Author: Creator of the signature.

Example Signature:

alert tcp 192.168.1.100 any -> 192.168.1.200 80 (content:”malware_pattern”; msg:”Potential malware detected”; sid:1234; rev:2)

Breakdown:

• Action: alert
• Header:
  • Protocol: tcp
  • Source IP: 192.168.1.100
  • Source Port: any
  • Direction: -> (outgoing traffic)
  • Destination IP: 192.168.1.200
  • Destination Port: 80 (HTTP)
• Rule Options:
  • content:"malware_pattern": Seeks content matching the specified pattern.
  • msg:"Potential malware detected": Alert message to be displayed.
  • sid:1234: Unique signature ID.
  • rev:2: Second version of the signature.

Conclusion

Understanding these core components empowers you to effectively interpret, configure, and even create detection signatures to enhance your security posture. By mastering signatures, you’ll be better equipped to identify and mitigate potential threats within your networks, ensuring the safety and integrity of your digital assets.

As a security analyst, you may be tasked with writing, customizing, or
testing signatures. To do this, you’ll
use IDS tools. So in this section, we’ll examine signature syntax and by the end, you’ll be able to
read a signature. A signature specifies
detection rules. These rules outline
the types of network intrusions you
want an IDS to detect. For example, a signature can be written to detect and alert on suspicious traffic attempting
to connect to a port. Rule language
differs depending on different network intrusion
detection systems. The term network intrusion
detection system is often abbreviated as the acronym N-I-D-S
and pronounced NIDS. Generally, NIDS rules
consists of three components: an action, a header,
and rule options. Now, let’s examine each of these three components
in more detail. Typically, the action is the first item specified
in a signature. This determines the
action to take if the rule criteria
matches are met. Actions differ across
NIDS rule languages, but some common actions are:
alert, pass, or reject. Using our example, if a
rule specifies to alert on suspicious network traffic that establishes an unusual
connection to a port, the IDS will inspect the traffic packets
and send out an alert. The header defines the
signature’s network traffic. These include
information such as source and destination
IP addresses, source and destination ports, protocols, and
traffic direction. If we want to
detect an alert on suspicious traffic
connecting to a port, we have to first
define the source of the suspicious
traffic in the header. Suspicious traffic
can originate from IP addresses outside
the local network. It can also use specific
or unusual protocols. We can specify
external IP addresses and these protocols
in the header. Here’s an example of how header information may
appear in a basic rule. First, we can observe
that the protocol, TCP, is the first listed
item in the signature. Next, the source IP address 10.120.170.17 and the
source port number is specified as being any. The arrow in the middle
of the signature indicates the direction
of the network traffic. So we know it’s originating
from the source IP 10.120.170.17 from any port going to the following
destination IP address 133.113.202.181
and destination port 80. The rule options
lets you customize signatures with
additional parameters. There are many different
options available to use. For instance, you can
set options to match the content of a network packet to detect malicious payloads. Malicious payloads reside in
a packet’s data and perform malicious activity like
deleting or encrypting data. Configuring rule options helps in narrowing down
network traffic, so you can find exactly
what you’re looking for. Typically, rule options
are separated by semi-colons and enclosed
in parentheses. In this example, we can examine that the rule options
are enclosed in a pair of parentheses and are also separated with semi-colons. The first rule option, msg, which stands for message, provides the alert’s text. In this case, the alert
will print out the text: “This is a message.” There’s also the option sid, which stands for signature ID. This attaches a unique
id to each signature. The rev option
stands for revision. Each time a signature
is updated or changed, the revision number changes. Here, the number 1 means it’s the first version
of the signature. Great! Now you’ve
developed another skill in your journey towards
becoming a security analyst: how to read signatures. There’s so much more to
learn and coming up, we’ll discuss tools
that use signatures.

Examine Signatures with Suricata: A Hands-on Tutorial

In the realm of cybersecurity, understanding and analyzing signatures is fundamental for effectively deploying intrusion detection systems like Suricata. This tutorial will guide you through examining pre-written and custom signatures within Suricata, equipping you with the skills to interpret their function and tailor them to your specific needs.

Materials:

• A Linux machine with Suricata installed
• Basic familiarity with the command line

Steps:

1. Locate Signature Files:

Navigate to the Suricata configuration directory:

cd /etc/suricata/

Locate the rules folder, where pre-written and custom signatures reside:

cd rules

2. Explore Pre-written Signatures:

List the contents of the folder to identify different rule sets:

ls

For instance, you might find pre-written rules for protocols like HTTP, DNS, and SMB. Choose a relevant protocol folder, such as http.

3. Examine a Specific Signature:

Select a signature file, for example, http.rules, and open it using a text editor like nano:

nano http.rules

4. Deconstruct the Signature:

Each signature line corresponds to specific detection criteria. Let’s break down the key components:

– Action: Specifies what Suricata does when the rule matches, e.g., alert, drop, or log. – Header: Defines the network traffic characteristics, including: * Protocol (e.g., http) * Source and destination IP addresses or networks * Source and destination ports * Traffic direction (inbound/outbound) – Rule Options: Refine the signature match with additional conditions, such as: * content: Search for specific patterns within packets (e.g., malicious payloads) * time: Limit rule activation to specific periods * sid: Unique identifier for the signature * rev: Revision number indicating updates

5. Analyze a Signature Example:

Consider the following line from the http.rules file:

alert tcp HOME_NET any -> EXTERNAL_NET any (msg:”HTTP GET on wire”; flow:established; content:”GET”; sid:1000; rev:1)

Breakdown:

• Action: alert triggers an alert when the rule matches.
• Header:
  • Protocol: tcp
  • Source: HOME_NET (any port)
  • Destination: EXTERNAL_NET (any port)
  • Direction: Traffic leaving the home network.
• Rule Options:
  • msg: Displays “HTTP GET on wire” on alert.
  • flow: Matches only established connections.
  • content: Looks for the text “GET” in network packets.
  • sid: Unique identifier 1000.
  • rev: First version of the signature.

This signature alerts when Suricata detects an HTTP “GET” request leaving the home network.

6. Modify and Test Signatures (Optional):

With a grasp of signature composition, you can modify existing rules or create new ones to address specific threats in your environment. Remember to thoroughly test any modifications to avoid false positives and ensure effective detection.

Bonus:

• Explore other rule sets like dns.rules or smb.rules to understand how Suricata detects threats in different protocols.
• Use the suricata -C rules/suricata.rules command to check rule syntax and identify potential errors.

By mastering the art of examining and adapting signatures, you can unleash the full potential of Suricata and keep your network safe from lurking threats. Remember, knowledge is power – keep exploring and learning to stay ahead of the curve in the ever-evolving cybersecurity landscape!

Which of the following is true when it comes to analyzing Suricata signatures?

The first field specifies the action.

In a Suricata signature, the first field specifies the action.

Previously, you learned about signature-based
analysis. You also learned how to read signatures used in network-based
intrusion detection systems. Here, we’ll use an open source signature-based
IDS called Suricata to examine a signature. Many NIDS technologies come with
pre-written signatures. You can think of these signatures
as customizable templates. Sort of like different templates
available in a word processor. These signature templates provide you
with a starting point for writing and defining your rules. You can also write and add your own rules. Let’s examine a pre-written
signature through Suricata. On this Linux machine running Ubuntu,
Suricata is already installed. Let’s examine some of its files by
changing directories to the etc directory and into the suricata directory. This is where all of Suricata’s
configuration files live. Next, we’ll use the ls command to list
the contents of the suricata directory. There’s a couple of different files in
here, but we’ll focus on the rules folder. This is where the pre-written
signatures are. You can also add custom signatures here. We’ll use the cd command followed by
the name of the folder to navigate to that folder. Using the ls command, we can observe that
the folder contains some rule templates for different protocols and services. Let’s examine the custom.rules
file using the less command. As a quick refresher, the less command
returns the content of a file one page at a time which makes it easy to move
forward and backward through the content. We’ll use the arrow key to scroll up. Lines that begin with a pound sign (#)
are comments meant to provide context for those who read them and
are ignored by Suricata. The first line says Custom rules
example for HTTP connection. This tells us that this file contains
custom rules for HTTP connections. We can observe that there’s a signature. The first word specifies
the signature’s ACTION. For this signature, the action is alert. This means that the signature generates an
alert when all of the conditions are met. The next part of
the signature is the HEADER. It specifies the protocol http.
The source IP address is HOME_NET and source port is defined as ANY. The arrow indicates the direction of
traffic coming from the home network and going to the destination IP address
EXTERNAL_NET and ANY destination port. So far, we know that this signature
triggers an alert when it detects any HTTP traffic leaving the home network and
going to the external network. Let’s examine the remainder of
the signature to identify if there’s any additional conditions
the signature looks for. The last part of the signature
includes the RULE OPTIONS. They’re enclosed in parentheses and
separated by semicolons. There’s many options listed here, but
we’ll focus on the message, flow, and content options. The message option will show the message
“GET on wire” once the alert is triggered. The flow option is used to match on
direction of network traffic flow. Here, it’s established. This means that a connection
has been successfully made. The content option inspects
the content of a packet. Here, between the quotation marks,
the text GET is specified. GET is an HTTP request that’s used to
retrieve and request data from a server. This means the signature will match if
a network packet contains the text GET, indicating a request. To summarize, this signature alerts
anytime Suricata observes the text GET in an HTTP connection from the home network,
going to the external network. Every environment is different and
in order for an IDS to be effective,
signatures must be tested and tailored. As a security analyst,
you may test, modify, or create IDS signatures to improve the
detection of threats in an environment and reduce the likelihood of false positives. Coming up,
we’ll examine how Suricata logs events. Meet you there.

# Deciphering the Network’s Story: A Guide to Examining Suricata Logs

In the world of cybersecurity, logs are the silent storytellers, revealing crucial insights into the events occurring within your network. Suricata, a powerful intrusion detection system, meticulously documents its findings in log files. This tutorial will equip you with the skills to navigate and interpret these logs, empowering you to uncover potential threats and safeguard your digital assets.

Prerequisites:

• Basic understanding of cybersecurity concepts and Suricata’s role as an IDS.
• Access to a system running Suricata with log files.
• Familiarity with command-line tools or a log analysis software.

Steps:

1. Locate the Logs:
   • Default location on Linux systems: /var/log/suricata/
   • Configuration file (suricata.yaml) might specify a different location.
2. Identify Log Types:
   • Alert Logs (eve.json or fast.log): Contain security-relevant events triggered by signatures.
   • Network Telemetry Logs (http.log, dns.log etc.): Record general network traffic flows.
3. Choose Your Tool:
   • Command-Line Tools: cat, grep, less, awk for basic text manipulation and searching.
   • Log Analysis Software: Dedicated tools for advanced filtering, visualization, and correlation.
4. Inspect Log Structure:
   • EVE JSON format: Key-value pairs for easier extraction.
   • Common fields:
     • timestamp: Event time
     • event_type: Alert or telemetry log type
     • src_ip, dest_ip: Source and destination IP addresses
     • protocol: Network protocol (TCP, UDP, etc.)
     • alert: Signature details if applicable
     • http, dns etc.: Protocol-specific fields for telemetry logs
5. Filter and Search:
   • Use tools to narrow down relevant events:
     • Time range: Focus on specific time periods.
     • IP addresses: Investigate specific hosts or networks.
     • Signature IDs: Examine alerts triggered by particular rules.
6. Interpret Findings:
   • Analyze alert logs for potential threats and prioritize investigation.
   • Use network telemetry logs to reconstruct network activity and understand context.
   • Correlate logs with other data sources (e.g., firewall logs, system logs) for a comprehensive view.

Additional Tips:

• Regularly Review Logs: Proactive analysis can uncover threats early on.
• Automate Log Analysis: Set up alerts for critical events or use tools for continuous monitoring.
• Contextualize Findings: Consider network topology, asset criticality, and threat intelligence for informed decision-making.
• Tail Logs in Real-Time: Use tail -f to monitor logs live for immediate insights.
• Utilize Logging Options: Explore Suricata’s configuration for log customization and output tuning.

Remember, effective log analysis is an ongoing process. By mastering the art of examining Suricata logs, you’ll gain invaluable visibility into your network’s activities, enabling you to detect, investigate, and respond to threats swiftly and effectively. Stay vigilant and keep exploring the stories hidden within the logs!

Now let’s examine some logs
generated by Suricata. In Suricata, alerts and events are output
in a format known as EVE JSON. EVE stands for Extensible Event Format and
JSON stands for JavaScript Object Notation. As you previously learned, JSON uses
key-value pairs, which simplifies both searching and
extracting text from log files. Suricata generates two types of log data:
alert logs and network telemetry logs. Alert logs contain information that’s
relevant to security investigations. Usually this is the output of signatures
which have triggered an alert. For example, a signature that detects
suspicious traffic across the network generates an alert log that
captures details of that traffic. While network telemetry logs contain
information about network traffic flows, network telemetry is not always security
relevant, it’s simply recording what’s happening on a network, such as a
connection being made to a specific port. Both of these log types provide
information to build a story during an investigation. Let’s examine an example
of both log types. Here’s an example of an event log. We can tell that this event is an alert
because the event type field says alert. There’s also details about the activity
that was logged including IP addresses and the protocol. There are also details about the signature
itself, such as the message and id. From the signature’s message, it appears that this alert relates
to the detection of malware. Next up, we have an example of
a network telemetry log, which shows us the details of an http
request to a website. The event type field tells
us it’s an http log. There’s details about the request. Under hostname,
there’s the website that was accessed. The user agent is the name of software
that connects you to the website. In this case,
it’s the web browser Mozilla 5.0. And the content type, which is the data
the http request returned. Here it’s specified as HTML text. That sums it up on the different
types of log outputs. In the upcoming activity, you’ll be applying what we just explored
by getting hands-on with Suricata. Have fun!

Security Information and Event Management (SIEM) tools are the Swiss Army knives of security analysts, offering a central hub for data collection, analysis, and threat detection. But just like any trusty tool, it’s essential to periodically re-evaluate your SIEM’s effectiveness and ensure it’s still aligned with your evolving security needs.

Why Re-examine Your SIEM?

The security landscape is constantly shifting, with new threats and vulnerabilities emerging all the time. Your SIEM, however, might not be keeping pace. Re-examining your SIEM helps you:

• Identify gaps in coverage: Are you collecting and analyzing data from all your critical sources? Are there blind spots that attackers could exploit?
• Assess rule effectiveness: Are your SIEM rules generating too many false positives, drowning out real threats? Or are they missing subtle indicators of compromise?
• Optimize resource allocation: Are you overburdening your SIEM with irrelevant data? Can you streamline resource allocation for better performance?
• Adapt to new threats: Can your SIEM handle the latest attack vectors and malware strains? Does it integrate with other security tools for a holistic view?

Steps for Re-examining Your SIEM

1. Review Data Sources:
   • Mapping the terrain: Make a comprehensive list of all data sources generating security-relevant information (firewalls, endpoints, applications, cloud platforms).
   • Completeness check: Ensure your SIEM is ingesting data from all identified sources. Are there any gaps or inconsistencies?
   • Data prioritization: Analyze the volume and value of data from each source. Prioritize collection and analysis based on criticality and threat potential.
2. Evaluate Rule Effectiveness:
   • False friend fatigue: Analyze your SIEM logs for a baseline of false positives and negatives. Are existing rules generating too much noise?
   • Fine-tuning the filters: Refine your rules to minimize false alerts while capturing genuine threats. Consider factors like user behavior, device type, and anomaly detection.
   • Threat intelligence integration: Leverage threat intelligence feeds to update your rules and stay ahead of emerging attack patterns.
3. Optimize Resource Allocation:
   • Data filtering at the source: Implement pre-filtering mechanisms at data sources to reduce irrelevant information reaching your SIEM.
   • Data retention policies: Define data retention policies based on compliance requirements and historical analysis needs. Don’t overload your SIEM with unnecessary data.
   • Hardware and software upgrades: Consider upgrading your SIEM hardware and software to handle increased data volume and complexity.
4. Adapt to New Threats:
   • Threat landscape awareness: Stay updated on the latest cyber threats and attack vectors. Research emerging malware strains and vulnerabilities relevant to your environment.
   • SIEM capabilities assessment: Evaluate your SIEM’s ability to detect and respond to these new threats. Does it offer features like threat hunting, behavioral analysis, and incident response tools?
   • Integration with other security tools: Consider integrating your SIEM with other security solutions like endpoint detection and response (EDR) or threat intelligence platforms for a broader security posture.

Conclusion:

Re-examining your SIEM is not a one-time event but an ongoing process to ensure it remains your most valuable security ally. By regularly assessing its coverage, rule effectiveness, resource allocation, and adaptability, you can keep your SIEM sharp and your organization secure in the ever-evolving threat landscape.

Remember, your SIEM is only as effective as the data it ingests and the rules it uses. By continually refining these aspects, you can transform your SIEM from a data repository into a proactive threat detection and response engine.

Which of the following steps are involved in the SIEM process for data collection? Select three answers.

Normalize, Collect and process, Index

The SIEM process for data collection is made up of the following three steps: collect and process, normalize, and index. Indexing is the step that sorts data so it can be easily searched and accessed.

As a security analyst, you’ll need to be
able to quickly access the relevant data required to perform your duties. Whether it’s triaging alerts,
monitoring systems, or analyzing log data during
incident investigations, a SIEM is the tool for this job. As a quick review, a SIEM is
an application that collects and analyzes log data to monitor critical
activities in an organization. It does this by collecting, analyzing, and reporting on security data
from multiple sources. Previously, you learned about the SIEM
process for data collection. Let’s revisit this process. First, SIEM
tools COLLECT AND PROCESS enormous amounts of data generated by devices and
systems from all over an environment. Not all data is the same.
As you already know, devices generate data
in different formats. This can be challenging because there is
no unified format to represent the data. SIEM tools make it easy for
security analysts to read and analyze data by NORMALIZING it. Raw data gets processed, so
that it’s formatted consistently and only relevant event
information is included. Finally, SIEM tools INDEX the data, so
it can be accessed through search. All of the events across all the different
sources can be accessed with your fingertips. Isn’t that useful? SIEM tools make it easy
to quickly access and analyze the data flows happening
across networks in an environment. As a security analyst, you may
encounter different SIEM tools. It’s important that
you’re able to adjust and adapt to whichever tool your
organization ends up using. With that in mind, let’s explore some SIEM
tools currently used in the security industry. Splunk is a data analysis platform. Splunk Enterprise Security provides
SIEM solutions that let you search, analyze, and visualize security data. First, it collects data from different
sources. That data gets processed and stored in an index. Then, it can be
accessed in a variety of different ways, like through search. Chronicle is Google Cloud’s SIEM,
which stores security data for search, analysis, and visualization. First, data gets forwarded to Chronicle. This data then gets normalized, or cleaned
up, so it’s easier to process and index. Finally, the data becomes available
to be accessed through a search bar. Next up, we’ll explore how to
search on these SIEM platforms.

Splunk, with its robust search capabilities, is a security analyst’s best friend when navigating the vast ocean of security event data. This tutorial equips you with the knowledge to craft effective Splunk queries, enabling you to quickly pinpoint relevant information and investigate potential threats.

Understanding the Splunk Search Bar:

Imagine the Splunk search bar as your captain’s compass, guiding you through the data seas. It’s where you type your search terms and commands to retrieve specific events.

Building Basic Queries:

1. Keywords: Start with simple keywords relevant to your search. For example, if you’re investigating unauthorized access attempts, your query might be “user=unknown AND login=fail.”
2. Operators: Logical operators like AND, OR, and NOT refine your search. AND narrows down results (e.g., “source=webserver AND error=500”), while OR broadens them (e.g., “user=admin OR user=root”). NOT excludes unwanted events (e.g., “source=firewall NOT severity=low”).
3. Wildcards: Use * and ? for flexibility. * matches any character sequence (e.g., “process*”), while ? matches any single character (e.g., “user=j?hn”).

Advanced Search Techniques:

1. Time Ranges: Specify a timeframe for your search using “@epoch” or relative time formats like “last 7 days.”
2. Fields and Values: Extract specific data from events using field names and values. For example, “source=IDS AND severity=high | stats count by dest_ip” groups events by destination IP for high-severity IDS alerts.
3. Subsearches: Nest searches within searches for deeper analysis. Imagine searching for failed logins followed by a specific file access event, like “user=hacker AND login=fail | search file_access=confidential_data.”

Tips for Effective Splunk Queries:

• Start simple: Begin with basic keywords and gradually add complexity as needed.
• Test and refine: Execute your query and analyze the results. Refine your search terms and operators to get the desired outcome.
• Use search commands: Splunk offers a plethora of commands for data manipulation, aggregation, and visualization. Explore the Splunk documentation to unlock their potential.
• Combine with filters: Leverage Splunk’s powerful filters to narrow down your search further based on specific criteria.

Beyond the Basics:

This tutorial lays the foundation for Splunk query construction. As you delve deeper, explore advanced techniques like regular expressions, custom searches, and data enrichment to unlock Splunk’s full analytical power. Remember, practice makes perfect, so keep querying and honing your skills to become a Splunk search master!

Additional Resources:

• Splunk Search Tutorial: https://docs.splunk.com/Documentation/Splunk/9.1.2/SearchReference/Search
• Splunk Search Reference: https://docs.splunk.com/Documentation/SCS/current/SearchReference/SearchCommandOverview
• Splunk Enterprise Security User Guide: https://docs.splunk.com/Documentation

By mastering Splunk queries, you transform this versatile tool from a data repository into a powerful investigative and analytical engine, safeguarding your organization from potential threats. So, set sail on your Splunk search journey and discover the hidden treasures within your security event data!

Do specific queries improve the speed and relevance of SIEM search results?

Yes

Specific queries improve the speed and relevance of SIEM search results.

Now that we’ve reviewed
how a SIEM works, let’s learn how to search and query events in a SIEM database. Data that’s been imported
into a SIEM can be accessed by entering queries into
the SIEM’s search engine. Massive amounts of data can
be stored in a SIEM database. Some of this data
may date back years. This can make searching for
security events challenging. For example, let’s say you’re searching to find a
failed login event. You search for the event using
the keywords: failed login. This is a very broad query, which can return thousands of results. Broad search queries like this, slow down the response
times of a search engine since it’s searching
across all the indexed data. But, if you specify
additional parameters, like an event ID and a
date and time range, you can narrow down the
search to get faster results. It’s important that
search queries are specific, so
that you can find exactly what you’re
looking for and save time in the search process. Different SIEM tools use
different search methods. For example, Splunk uses its own query language called Search Processing Language, or SPL for short. SPL has many different search
options you can use to optimize search
results, so that you can get the data
you’re looking for. For now, I’ll demonstrate a raw log search in Splunk
Cloud for events that reference errors or failures for a fictional online store
called Buttercup Games. First, we’ll use the search
bar to type in our query: buttercupgames error
OR fail* This search is
specifying the index, which is buttercupgames. We also specify the search
terms: error OR fail. The Boolean operator OR ensures that both of the keywords
will be searched. The asterisk at the
end of the term fail* is known
as a wildcard. This means it will search for all possible endings that
contain the term fail. This helps us expand
our search results because events may label
failures differently. For example, some events
may use the term failed. Next, we’ll select a time range using the time range picker. Remember, the more specific
our search is, the better. Let’s search for data
from the last 30 days. Under the search bar, we
have our search results. There’s a timeline,
which gives us a visual representation of the number of events
over a period. This can be helpful
in identifying event patterns such as
peaks in activity. Under the timeline, there’s
the events viewer, which gives us a list of events
that match our search. Notice how our search terms: buttercupgames and error are highlighted in each event. It doesn’t appear
that any events matching with the
term fail were found. Each event has a timestamp
and raw logged data. For the events with errors, it appears that there’s
an error relating to the HTTP cookies used in the
Buttercup Games website. At the bottom of
the raw log data, there’s some information
related to the data source, including the host name, source, and source type. This information tells
us where the event data originated from such as
a device or file. If we click on it,
we can choose to exclude it from the
search results. On the search bar,
we can examine that the search terms
have been changed and host!=www1
has been added, which means not to
include www1 hosts. Notice that the new
search results do not contain www1 as a host, but contain www2 and www3. This is just one of the many
ways that you can target your searches to retrieve
information you’re looking for. This search is known
as a raw log search. As a security analyst, you’ll use different
commands to optimize search performance for
faster search results. That completes
querying in Splunk. You’ve learned the importance
of effective queries and how to perform a
basic Splunk search. Coming up, you’ll learn how
to query events in Chronicle.

Chronicle empowers security analysts to navigate the ocean of security events with its powerful search capabilities. This tutorial equips you with the knowledge to craft effective Chronicle queries, enabling you to quickly pinpoint relevant information and investigate potential threats.

Understanding the Chronicle Search Canvas:

Imagine Chronicle’s search canvas as your investigation workbench. This is where you build your queries by combining search terms, filters, and operators.

Building Basic Queries:

1. Keywords: Begin with simple keywords relevant to your search. For example, if you’re investigating suspicious file access, your query might be “file_access AND (confidential OR sensitive).”
2. Unified Data Model (UDM) Fields: Chronicle organizes data using UDM fields like source, event_type, username, and file_hash. Utilize these fields for targeted searches.
3. Operators: Logical operators like AND, OR, and NOT refine your search. AND narrows down results (e.g., “source=firewall AND action=blocked”), while OR broadens them (e.g., “username=malicious OR ip=malware_c2”). NOT excludes unwanted events (e.g., “event_type!=heartbeat”).

Advanced Search Techniques:

1. Time Ranges: Specify a timeframe for your search using “@epoch” or relative times like “last 7 days.”
2. Filters: Narrow down your search by applying filters based on various criteria like device type, severity level, or specific timestamps.
3. Subsearches: Nest searches within searches for deeper analysis. Imagine searching for suspicious file access, followed by a specific user login event, like “file_access AND confidential | search username=suspicious_user.”
4. YARA-L Rules: For advanced threat detection, utilize YARA-L, a rule-based language, to define custom patterns for identifying specific activities or malware characteristics.

Tips for Effective Chronicle Queries:

• Start simple: Begin with basic keywords and gradually add complexity as needed.
• Test and refine: Execute your query and analyze the results. Refine your search terms and filters to get the desired outcome.
• Utilize UDM fields: Understand and leverage UDM fields for precise data exploration.
• Combine with filters: Employ filters to effectively narrow down your search and focus on relevant data.

Beyond the Basics:

This tutorial lays the foundation for Chronicle query construction. As you delve deeper, explore advanced techniques like regular expressions, custom time ranges, and data enrichment to unlock Chronicle’s full analytical power. Remember, practice makes perfect, so keep querying and honing your skills to become a Chronicle search master!

Additional Resources:

• Chronicle Search Tutorial: https://cloud.google.com/chronicle/docs
• Chronicle UDM Reference: https://cloud.google.com/chronicle/docs
• Chronicle YARA-L Guide: https://cloud.google.com/chronicle/docs

By mastering Chronicle queries, you transform this versatile tool from a data repository into a powerful investigative and analytical engine, safeguarding your organization from potential threats. So, set sail on your Chronicle search journey and discover the hidden treasures within your security event data!

Fill in the blank: Chronicle uses _____ to search through normalized data.

Unified Data Model (UDM)

Chronicle uses UDM to search through normalized data.

Chronicle allows you to
search and filter log data. In this video,
we’ll explore using Chronicle’s search field
to locate an event. Chronicle uses the
YARA-L language to define rules for detection. It’s a computer
language used to create rules for searching
through ingested log data. For example, you can use YARA-L
to write a rule to detect specific activities related to the exfiltration
of valuable data. Using Chronicle’s search field, you can search for fields
like hostname, domain, IP, URL, email, username, or file hash. Using the search field, you can enter different
types of searches. The default method of
search is using UDM search, which stands for
Unified Data Model. It searches through
normalized data. If you can’t find the
data you’re looking for searching the
normalized data, you have the option of
searching raw logs. Raw log search searches through the logs which have
not been normalized. From our earlier discussion
on the SIEM process, you may recall that raw logs get processed during the
normalization step. During normalization, all
of the relevant information from raw logs gets
extracted and formatted, making the data
easier to search. A reason we might need to
search raw logs is to find data that may not have been included in the normalized logs, like specific fields
which have not been normalized, or to troubleshoot
data ingestion problems. Let’s examine a UDM search for a failed login
using Chronicle. First, let’s click on the structured query
builder icon, so that we can perform
a UDM search. I’ll type in the search: metadata.event_type = “USER_LOGIN” AND security_result.action
= “BLOCK” Let’s break down
this UDM search. Since we are searching
for normalized data, we need to specify a search
that uses UDM format. UDM events have a set
of common fields. The metadata.event_type
field details the event’s type. Here, we’re asking
Chronicle to find an authentication activity
event, a user login. Next, there’s AND, which is a logical
operator that tells the search engine to
contain both terms. Finally, the
security_result.action field specifies a security action
such as allow or block. Here, the action is BLOCK. This means the user login
was blocked or failed. Now, we’ll press
the query button. We’re going to focus on
searching normalized data. We’re presented with a screen
with the search results. There’s lots of
information here. Under UDM Search, we can observe our search terms. There’s also a bar
graph timeline visualizing the failed
login events over a period. At a quick glance, this gives us a snapshot of the failed
login activity over time, allowing us to spot
possible patterns. Under the timeline, there’s
a list of events with timestamps associated
with this search. Under each event,
there’s an asset, which is the name of a device. For example, this event shows a failed login for
a user named alice. If we click the
event, we can open up the raw log associated
with the event. We can interpret these
raw logs for more detail about the event’s activity
during the investigation. To the left, there’s
Quick Filters. These are additional
fields or values that we can use to filter
the search results. For example, if we
click: target.ip, we are given a list
of IP addresses. If we click one of
these IP addresses, we can filter the search
results to contain only this target IP address. This helps us find specific data we’re looking for and helps us save time in the
process. Great work! Now you know how to perform
a search using Chronicle. In the upcoming activity, you’ll have the chance
to perform searches using the SIEM tools
we’ve just discussed.

Congratulations! You’ve made it
to the end of this section. You’ve made so
much progress in your security journey. Let’s review what we learned. You learned all about how to read and
analyze logs. You examined how log files are created and
used for analysis. You also compared different
types of common log formats and learned how to read them. You extended your understanding on
intrusion detection systems by comparing network-based systems and
host-based systems. You also learned how to
interpret signatures. You examined how signatures are written
and also how they detect, log, and alert on intrusions. You interacted with Suricata in the command line
to examine and interpret signatures and alerts. Lastly, you learned how to search in
SIEM tools like Splunk and Chronicle. You learned about the importance of
crafting tailored queries to locate events. At the forefront of incident response,
monitoring and analyzing network traffic for indicators
of compromise is one of the primary goals. Being able to perform in-depth log
analysis and knowing how to read and write signatures and how to access log data are all skills
that you’ll use as a security analyst.

Congratulations on
completing this course on detection and response! As you’ve progressed,
we’ve covered a wide range of
topics and tools. Let’s take a moment to
review what you’ve learned. First, we began with an overview of the incident
response lifecycle. You learned how security
teams coordinate their response efforts. And you explored the documentation, detection, and management tools used in incident response. Next, you learned how to monitor and analyze network traffic. You learned about capturing and analyzing packets using
packets sniffers. You also practiced using
tools like tcpdump to capture and
analyze network data to identify indicators
of compromise. Then, we explored
processes and procedures involved in the phases of the incident
response lifecycle. You learned about
techniques related to incident detection and analysis. You also learned about documentation like
chain of custody, playbooks, and final reports. We ended with
exploring strategies used for recovery and
post-incident activity. Finally, you learned how to
interpret logs and alerts. You explored Suricata
on the command line to read and understand
signatures and rules. You also used SIEM
tools like Splunk and Chronicle to search
for events and logs. As a security analyst, you’ll be presented with a
new challenge every day. Whether it’s
investigating evidence or documenting your work, you’ll use what you’ve
learned in this course to effectively
respond to incidents. I’m so glad to have been on this learning journey with you. You’ve done a fantastic job in expanding your knowledge and learning new tools to add
to your security toolbox. One of the things I love about the security field
is that there’s always something new to learn. And coming up, you’ll continue
your learning journey by exploring a programming
language called Python, which can be used to
automate security tasks. Keep up the great work!