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.
|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.
|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.
|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.
|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.
|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 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 full format of a Syslog message that is seen on the network has three distinct parts, as shown in the figure.
- PRI (priority)
- 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.
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
- 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