MODULE 25 - CERTIFICATION PREPARTION Flashcards
Alert Data Alert data consists of messages generated by intrusion prevention systems (IPSs) or intrusion detection systems (IDSs) in response to traffic that violates a rule or matches the signature of a known exploit.
A network IDS (NIDS), such as Snort, comes configured with rules for known exploits.
Alerts are generated by Snort and are made readable and searchable by the Sguil and Squert applications, which are part of the Security Onion suite of NSM tools.
Alert Data A testing site that is used to determine if Snort is operating is the tesmyids site.
Search for it on the internet.
It consists of a single webpage that displays only the following text uid=0(root) gid=0(root) groups=0(root).
If Snort is operating correctly and a host visits this site, a signature will be matched and an alert will be triggered.
This is an easy and harmless way to verify that the NIDS is running.
Alert Data The Snort rule that is triggered is:
alert ip any any -> any any (msg:”GPL ATTACK_RESPONSE id check returned root”; content:”uid=0|28|root|29|”; fast_pattern:only; classtype:bad-unknown; sid:2100498; rev:8;)
Alert Data This rule generates an alert if any IP address in the network receives data
from an external source that contains content with text matching the pattern of uid=0(root).
The alert contains the message GPL ATTACK_RESPONSE id check returned root.
The ID of the Snort rule that was triggered is 2100498.
Alert Data The highlighted line in the figure displays a Sguil alert that was generated by visiting the testmyids website.
The highlighted line in the figure displays a Sguil alert that was generated by visiting the testmyids website.
The Snort rule and the packet data for the content received from the testmyvids webpage is displayed in the lower right-hand area of the Sguil interface.
Sguil Console Showing Test Alert from Snort IDS
https://snipboard.io/8AgTuU.jpg
Session and Transaction Data Session data is a record
of a conversation between two network endpoints, which are often a client and a server.
The server could be inside the enterprise network or at a location accessed over the internet.
Session data is data about the session, not the data retrieved and used by the client.
Session data will include identifying information such as the five tuples of source and destination IP addresses, source and destination port numbers, and the IP code for the protocol in use.
Data about the session typically includes a session ID, the amount of data transferred by source and destination, and information related to the duration of the session.
Session and Transaction Data Zeek, formerly Bro, is a
network security monitoring tool you will use in labs later in the course.
The figure shows a partial output for three HTTP sessions from a Zeek connection log.
Explanations of the fields are shown below the figure.
Zeek Session Data - Partial Contents
https://snipboard.io/CqpZbi.jpg
Session and Transaction Data
Transaction data consists of the messages that are exchanged during network sessions.
These transactions can be viewed in packet capture transcripts.
Device logs kept by servers also contain information about the transactions that occur between clients and servers.
For example, a session might include the downloading of content from a webserver, as shown in the figure.
The transactions that represent the requests and replies would be logged in an access log on the server or by a NIDS like Zeek.
The session is all traffic involved in making up the request, the transaction is the request itself.
Session and Transaction Data Transaction Data
TRANSCATION DATA RECORD AS A WEB SERVER ACCESS LOG ENTRY.
https://snipboard.io/zhRZr0.jpg
Full Packet Captures
Full packet captures are the most detailed network data that is generally collected.
Because of the amount of detail, they are also the most storage and retrieval intensive types of data used in NSM.
Full packet captures contain not only data about network conversations, like session data.
Full packet captures also contain the actual contents of the conversations.
Full packet captures contain the text of email messages, the HTML in webpages, and the files that enter or leave the network.
Extracted content can be recovered from full packet captures and analyzed for malware or user behavior that violates business and security policies.
The familiar tool Wireshark is very popular for viewing full packet captures and accessing the data associated with network conversations.
Full Packet Captures
The figure illustrates the interface for the Network Analysis Monitor component of Cisco Prime Infrastructure system, which, like Wireshark, can display full packet captures.
The figure illustrates the interface for the Network Analysis Monitor component of Cisco Prime Infrastructure system, which, like Wireshark, can display full packet captures.
Cisco Prime Network Analysis Module - Full Packet Capture
https://snipboard.io/gaium4.jpg
Statistical Data Like session data, statistical data is about network traffic.
Statistical data is created through the analysis of other forms of network data. Conclusions can be made that describe or predict network behavior from these analysis.
Statistical characteristics of normal network behavior can be compared to current network traffic in an effort to detect anomalies.
Statistics can be used to characterize normal amounts of variation in network traffic patterns in order to identify network conditions that are significantly outside of those ranges.
Statistically significant differences should raise alarms and prompt investigation.
Statistical Data Network Behavior Analysis (NBA) and Network Behavior Anomaly Detection (NBAD) are approaches to network security monitoring that use advanced analytical techniques to analyze NetFlow or Internet Protocol Flow Information Export (IPFIX) network telemetry data.
Techniques such as predictive analytics and artificial intelligence perform advanced analyses of detailed session data to detect potential security incidents.
Statistical Data An example of an NSM tool that utilizes statistical analysis is Cisco Cognitive Threat Analytics.
finds malicious activity that has bypassed security controls or entered the network through unmonitored channels (including removable media) and is operating inside an organization’s environment.
Cognitive Threat Analytics is a cloud-based product that uses machine learning and statistical modeling of networks. It creates a baseline of the traffic in a network and identifies anomalies.
It analyzes user and device behavior, and web traffic, to discover command-and-control communications, data exfiltration, and potentially unwanted applications operating in the infrastructure.
The figure illustrates an architecture for Cisco Cognitive Threat Analytics.
Cisco Cognitive Threat Analytics
https://snipboard.io/rt6kEa.jpg
End Device Logs Host Logs host-based intrusion detection systems (HIDS) run on individual hosts.
HIDS not only detects intrusions, but in the form of host-based firewalls, can also prevent intrusion.
This software creates logs and stores them on the host.
This can make it difficult to get a view of what is happening on hosts in the enterprise, so many host-based protections have a way to submit logs to centralized log management servers.
In this way, the logs can be searched from a central location using NSM tools.
Host Logs HIDS systems can use agents to submit logs to management servers.
OSSEC, a popular open-source HIDS, includes a robust log collection and analysis functionality.
Search OSSEC on the internet to learn more.
Microsoft Windows includes several methods for automated host log collection and analysis.
Tripwire offers a HIDS for Linux that includes similar functionality.
All can scale to larger enterprises.
Host Logs Microsoft Windows host logs are visible locally through Event Viewer.
Event Viewer keeps four types of logs:
Application logs System logs Setup logs Security logs Command-line logs
Host Logs Microsoft Windows host logs are visible locally through Event Viewer.
Event Viewer keeps four types of logs:
Application logs System logs Setup logs Security logs Command-line logs
Host Logs Event Viewer keeps four types of logs: Application logs
These contain events logged by various applications.
Host Logs Event Viewer keeps four types of logs: System logs
These include events regarding the operation of drivers, processes, and hardware.
Host Logs Event Viewer keeps four types of logs: Setup logs
These record information about the installation of software, including Windows updates.
Host Logs Event Viewer keeps four types of logs: Security logs
These record events related to security, such as logon attempts and operations related to file or object management and access.
Host Logs Event Viewer keeps four types of logs: Command-line logs
Attackers who have gained access to a system, and some types of malware, execute commands from the command-line interface (CLI) rather than a GUI.
Logging command line execution will provide visibility into this type of incident.
Host Logs Various logs can have different event types.
Security logs consist only of audit success or failure messages.
On Windows computers, security logging is carried out by the Local Security Authority Subsystem Service (LSASS), which is also responsible for enforcing security policies on a Windows host. LSASS runs as lsass.exe.
It is frequently faked by malware. It should be running from the Windows System32 directory.
If a file with this name, or a camouflaged name, such as 1sass.exe, is running or running from another directory, it could be malware.
Host Logs Windows Events are identified by ID numbers and brief descriptions.
An encyclopedia of security event IDs, some with additional details, is available from Ultimate Windows Security on the web.
Host Logs Event Type : Error
Description:
An error is an event that indicates a significant problem such as loss of data or loss of functionality.
For example, if a service fails to load during startup, an error event is logged.
Host Logs Event Type : Warning
Description:
A Warning is an event that is not necessarily significant but may indicate a possible future problem.
For example, when disk space is low, a warning event is logged.
If an application can recover from an event without loss of functionality or data, it can generally classify the event as a warning event.
Host Logs Event Type : Information
Description:
An information event describes the successful operation of an application, driver, or service.
For example, when a network driver loads successfully, it may be appropriate to log an information event.
Note that it is generally inappropriate for a desktop application to log an event each time it starts.
Host Logs Event Type : Success Audit
A success audit is an event that records an audited security access attempt that is successful.
For example, a user’s successful attempt to log on to the system is logged as a success audit event.
Host Logs Event Type : Failure Audit
A failure audit is an event that records an audited security access attempt that fails.
For example, if a user tries to access a network drive and fails, the attempt is logged as a failure audit event.
Syslog Syslog incudes specifications formessage formats, a client-server application structure, and network protocol.
Many different types of network devices can be configured to use the syslog standard to log events to centralized syslog servers.
Syslog Syslog incudes specifications formessage formats, a client-server application structure, and network protocol.
Many different types of network devices can be configured to use the syslog standard to log events to centralized syslog servers.
Syslog is a client/server protocol. Syslog was defined within the Syslog working group of the IETF (RFC 5424) and is supported by a wide variety of devices and receivers across multiple platforms.
Syslog is a client/server protocol. Syslog was defined within the Syslog working group of the IETF (RFC 5424) and is supported by a wide variety of devices and receivers across multiple platforms.
The Syslog sender sends a small (less than 1KB) text message to the Syslog receiver.
The Syslog receiver is commonly called “syslogd,” “Syslog daemon,” or “Syslog server.” Syslog messages can be sent via UDP (port 514) and/or TCP (typically, port 5000).
While there are some exceptions, such as SSL wrappers, this data is typically sent in plaintext over the network.
The Syslog sender sends a small (less than 1KB) text message to the Syslog receiver.
The Syslog receiver is commonly called “syslogd,” “Syslog daemon,” or “Syslog server.” Syslog messages can be sent via UDP (port 514) and/or TCP (typically, port 5000).
While there are some exceptions, such as SSL wrappers, this data is typically sent in plaintext over the network.
The full format of a Syslog message that is seen on the network has three distinct parts, as shown in the figure.
PRI (priority) HEADER MSG (message text)
The full format of a Syslog message that is seen on the network has three distinct parts, as shown in the figure.
PRI (priority) HEADER MSG (message text)
Syslog PRI (priority)
The PRI consists of two elements, the Facility and Severity of the message, which are both integer values.
The Facility consists of broad categories of sources that generated the message, such as the system, process, or application.
The Facility value can be used by logging servers to direct the message to the appropriate log file.
The Severity is a value from 0-7 that defines the severity of the message.
Syslog Syslog Packet Format
Syslog Packet Format
https://snipboard.io/YM0Plj.jpg
Syslog Syslog packet descriptions:
FACILITY SEVERITY PRIORITY
Syslog Syslog packet descriptions: FACILITY
Note: Facility codes between 15 and 23 (local0-local7) are not assigned a keyword or name. They can be assigned to different meanings depending on the use context.
Also, various operating systems have been found to utilize both facilities 9 and 15 for clock messages.
The HEADER section of the message contains the timestamp in MMM DD HH:MM:SS format. If the timestamp is preceded by the period (.) or asterisk (*) symbols, a problem is indicated with NTP. The HEADER section also includes the hostname or IP address of the device that is the source of the message.
The MSG portion contains the meaning of the syslog message. This can vary between device manufacturers and can be customized.
Therefore, this portion of the message is the most meaningful and useful to the cybersecurity analyst.
