As previously discussed, host-based intrusion detection systems (HIDS) run on individual hosts. HIDS not only detects intrusions but in the form of host-based firewalls, which 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.
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.
Microsoft Windows host logs are visible locally through Event Viewer. Event Viewer keeps four types of logs:
Microsoft Windows host logs are visible locally through Event Viewer. Event Viewer keeps four types of logs:
- Application logs – These contain events logged by various applications.
- System logs – These include events regarding the operation of drivers, processes, and hardware.
- Setup logs – These record information about the installation of software, including Windows updates.
- Security logs – These record events related to security, such as logon attempts and operations related to file or object management and access.
- 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.
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.
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.
The table explains the meaning of the five Windows host log event types.
| Event Type | Description |
|---|---|
| Error | 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. |
| Warning | 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. |
| Information | 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. |
| 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. |
| 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 includes specifications for message 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 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 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.
The figure shows three main sections, the p r i section of 8 bits that has the words severity, facility over it, header with the words timestamp, hostname over it, and msg. At the bottom is 1024 bytes.
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.
Server Logs
Server logs are an essential source of data for network security monitoring. Network application servers such as email and web servers keep access and error logs. DNS proxy server logs which document all the DNS queries and responses that occur on the network are especially important.
DNS proxy logs are useful for identifying hosts that may have visited dangerous websites and for identifying DNS data exfiltration and connections to malware command-and-control servers. Many UNIX and Linux servers use Syslog. Others may use proprietary logging. The contents of log file events depend on the type of server.
Two important log files to be familiar with are the Apache webserver access logs and Microsoft Internet Information Server (IIS) access logs. Examples of each are shown below.
Two important log files to be familiar with are the Apache webserver access logs and Microsoft Internet Information Server (IIS) access logs. Examples of each are shown below.
Apache Access Log
203.0.113.127 – dsmith [10/Oct/2016:10:26:57 - 0500] "GET /logo_sm.gif HTTP/1.0" 200 2254 "http://www.example.com/links.html" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0"
IIS Access Log
6/14/2016, 16:22:43, 203.0.113.24, -, W3SVC2, WEB3, 198.51.100.10, 80, GET, /home.htm, -, 200, 0, 15321, 159, 15, HTTP/1.1, Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0), -, http://www.example.com
SIEM and Log Collection
Security Information and Event Management (SIEM) technology is used in many organizations to provide real-time reporting and long-term analysis of security events, as shown in the figure.
The figure shows the S I E M circle in the middle with text boxes around the top of it and each textbox has an arrow pointing to s i e m. Textboxes: threat intelligence, asset management, log storage; net flow telemetry; full packet captures; antimalware devices; i d s / i p s; firewalls; h i d s; server logs and Syslog. Four arrows come out from s i e m circle and each arrow has a textbox: compliance reporting, dashboards and reports, alerts and automation, and incident management system.
SIEM combines the essential functions of security event management (SEM) and security information management (SIM) tools to provide a comprehensive view of the enterprise network using the following functions:
- Log collection – Event records from sources throughout the organization provide important forensic information and help to address compliance reporting requirements.
- Normalization – This maps log messages from different systems into a common data model, enabling the organization to connect and analyze related events, even if they are initially logged in different source formats.
- Correlation – This links logs and events from disparate systems or applications, speeding detection of and reaction to security threats.
- Aggregation – This reduces the volume of event data by consolidating duplicate event records.
- Reporting – This presents the correlated, aggregated event data in real-time monitoring and long-term summaries, including graphical interactive dashboards.
- Compliance – This is reporting to satisfy the requirements of various compliance regulations.
A popular SIEM is Splunk, which is made by a Cisco partner. The figure shows a Splunk Threat Dashboard. Splunk is widely used in SOCs. Another popular SIEM solution is Security Onion with ELK, which consists of the integrated Elasticsearch, Logstash, and Kibana applications. Security Onion includes other open-source network security monitoring tools.
Splunk Threat Dashboard
As we know, security orchestration, automation, and response (SOAR) takes SIEM and goes beyond into automating security response workflows and facilitating incidence response. Because of the importance of network security, numerous companies have brought excellent products to the security tools market.
However, these tools lack compatibility and require monitoring multiple independent product dashboards in order to process the many alerts that they generate. Because of the lack of cybersecurity professionals to monitor and analyze the large volume of security data, it is important that tools from multiple vendors can be integrated into a single platform.
Integrated security platforms go beyond SIEM and SOAR to unify multiple security technologies, processes, and people into a unified team whose components build on rather than impede each other. Security platforms such as Cisco SecureX, Fortinet Security Fabric, and Paloalto Networks Cortex XDR promise to address network security monitoring complexity by integrating multiple functions and data sources into a single platform that will greatly enhance alert accuracy while offering a robust defence.
Leave a Reply