User:Jbuchanan 1/Security information and event management

History
Monitoring system logs has grown more prevalent as complex cyber-attacks force compliance and regulatory mechanisms to mandate logging security controls within a Risk Management Framework. Logging levels of a system started with the primary function of troubleshooting system errors or debugging code compiled and run. As operating systems and networks have increased in complexity, so has the event and log generation on these systems. In comparison, the logging of system, security, and application logs are not the only way to perform incident response. They do offer the capability to trace the activities of nearly any system or user-related movement throughout a given period.

From the late 1970’s we witnessed the formation of working groups to help establish the criteria for the management of auditing and monitoring programs and what and how system logs can be used for insider threat, incident response, and troubleshooting. See, Basis for Audit and Evaluation of Computer Security from National Institute of Standards and Technology (NIST) Special Publication 500-19 published in 1977.

With Risk Management Frameworks (RMF) being implemented worldwide in nearly all sectors of industry auditing and monitoring is a core element of information assurance and information security. Information assurance personnel, cybersecurity engineers, and analysts can use logging information to perform critical security functions in near real time. These items are driven by governance models that integrate or use auditing and monitoring as a basis for that analytical work.

As information assurance matured in the late 1990’s and moving into the 2000’s there became a need for system logs to be centralized. This provides a means for records to be centrally located and viewed and provides centralized management as a ‘nerve center’ for all machines on a given network.

This centralization and consolidation of system data would provide significantly more than just a holistic view. Still, now organizations could use the logging data for operational use cases and help with performance and networking-based communication troubleshooting. The term Security Information and Event Management (SIEM) is now commonplace and there are obvious variations of the same acronym in this article. The term SIEM is primarily a moniker forcing all logs into a single place to provide a single pane of glass for security and network operations to perform analysis.

The National Institute of Standards and Technology provide the following definition for Security Information Event Management (SIEM):  "“Application that provides the ability to gather security data from information system components and present that data as actionable information via a single interface.”"Information assurance has become a forcing function for system logging. System logging can enable a degree of traceability for an account on a system used to perform system actions. In combination with the operating system, the SIEM has the capability to take the system logs and send them to a centralized location for searching.

On May 17, 2021 United States President Joseph Biden signed Executive Order 14028 Improving the Nations Cybersecurity. This Executive Order mandates endpoint protection, further defining logging requirements, and implementing audit logging in a unified way, and enhance the capabilities to be able to give greater insight into system and account actions. Audit logs were identified in three separate technical areas all relating to incident response and knowing what is happening on a system at a given time. This Executive Order is in response to an increase in cyber-attacks that use ransomware to cripple critical infrastructure components related to national security and the public. Enhancing existing information assurance security controls as part of a Risk Management Framework is an expedient mechanism to force compliance and justify funding based on these Presidential requirements.

Security Information and Event Management (SIEM) & Information Assurance
Published in September of 2006, NIST SP 800-92 Guide to Computer Security Log Management is the primary document used in the NIST Risk Management Framework for what should be auditable. While not definitive or exhaustive as there have been significant changes in technology since 2006 this guidance anticipated industry growth as the document is still relevant. This document pre-dates many modern SIEM technologies that are well known today as evident by no reference to the term "SIEM". NIST is not the only guidance for regulatory mechanisms for auditing and monitoring that are encouraged to use SIEM solutions instead de-centralized individual host based checks. NIST identifies several public and private entities with their own logging guidance that may enforce its own requirements; Federal Information Security Management Act of 2002 (FISMA), Gramm-Leach-Bliley Act (GLBA) , Health Insurance Portability and Accountability Act of 1996 (HIPAA) , Sarbanes-Oxley Act (SOX) of 2002 , Payment Card Industry Data Security Standard (PCI DSS) , and International Organization for Standardization (ISO) 27001. It is not uncommon for NIST documents to be referenced in public and private organizations.

NIST SP 800-53 AU-2 Event Monitoring is a core security control for enabling logging functionality to support the information assurance process for all auditing throughout a system. AU-2 Event Monitoring also serves as a critical basis for continuous monitoring for information assurance and cybersecurity engineering efforts throughout a network. It is common that the SIEM solution be used as a core tool or suite of tools to support this effort. Depending on the system categorization with regard to impact to the Confidentiality, Integrity, and Availability (CIA) of a system are are generally five specific requirements needed to satisfy base logging requirements of a federal system (AU-2, a-e). It is important to understand the security control requirements with regard to the SIEM infrastructure and operation. Below is the security control requirements for AU-2. The [Assignment: organization-defined...] is left blank for the organization to determine what is appropriate for its enterprise. Executive Order 144028 seeks to unify the inputs across all federal agencies. a. Identify the types of events that the system is capable of logging in support of the audit function: [Assignment: organization-defined event types that the system is capable of logging];

b. Coordinate the event logging function with other organizational entities requiring audit-related information to guide and inform the selection criteria for events to be logged;

c. Specify the following event types for logging within the system: [Assignment: organization-defined event types (subset of the event types defined in AU-2a.) along with the frequency of (or situation requiring) logging for each identified event type];

d. Provide a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents; and

e. Review and update the event types selected for logging [Assignment: organization-defined frequency]. Events on a system could include and are not limited to credential changes, failed access attempts, role base or attribute changes to accounts, token based use, access attempts and failures, etc. While logging every system action to the system is possible it is often not advised based on volume of logs and actionable security relevant data. Organizations can use AU-2 a through e, as the basis to build from while adhering to other controls that may require or callout specific security auditing requirements in more granular detail. NIST SP 800-53 SI-4 System Monitoring is the security control that specifies the monitoring of the system. This monitoring is focused on monitoring systems that monitor the system. This can include hardware and software in unison do detect events and anomalies, malware, connections, and any other pertinent mechanism that can be used to detect attacks or indicators of potential attacks.

a. Monitor the system to detect:


 * 1. Attacks and indicators of potential attacks in accordance with the following monitoring objectives: [Assignment: organization-defined monitoring objectives]; and


 * 2. Unauthorized local, network, and remote connections;

b. Identify unauthorized use of the system through the following techniques and methods: [Assignment: organization-defined techniques and methods];

c. Invoke internal monitoring capabilities or deploy monitoring devices:


 * 1. Strategically within the system to collect organization-determined essential information; and


 * 2. At ad hoc locations within the system to track specific types of transactions of interest to the organization;

d. Analyze detected events and anomalies;

e. Adjust the level of system monitoring activity when there is a change in risk to organizational operations and assets, individuals, other organizations, or the Nation;

f. Obtain legal opinion regarding system monitoring activities; and

g. Provide [Assignment: organization-defined system monitoring information] to [Assignment: organization-defined personnel or roles] [Selection (one or more): as needed; [Assignment: organization-defined frequency]].

NIST SP 800-53 RA-10 Threat Hunting is a new base security control added to NIST 800-53 with the latest Revision 5 edit and publication. Threat hunting is the proactive defense of a network by combining all security information and actively looking for threats. In order to execute the operation the analysts and engineers need a repository of information and a SIEM solution is often used as a hub because all system logs would typically be sent to this centralized location. A threat hunting team is not limited to this approach, however, the SIEM solution should provide significant amounts of security relevant data.

a. Establish and maintain a cyber threat hunting capability to:


 * 1. Search for indicators of compromise in organizational systems; and


 * 2. Detect, track, and disrupt threats that evade existing controls; and

b. Employ the threat hunting capability [Assignment: organization-defined frequency].

NIST SP 800-53 R5 and the brief descriptions of AU-2, SI-4, and RA-10 depict how individual controls are all used as critical elements of the event, alerting, and monitoring via a SIEM. These controls combined with other technical security controls provided by NIST weave together a defense in depth system. The assurance of the system security is enforced with various risk assessments and continuous monitoring - often enhanced or streamlined with a SIEM product used across entire cybersecurity teams. There are many more technical controls that outline specific items that must be monitored, what has been identified is a cursory overlook of controls that are directly related to the event and audit gathering functionality and use in a SIEM tool.

Components
SIEM architectures may vary by vendor however, generally there are basic components that comprised for the SIEM engine.

The essential components of a SIEM are as follows:


 * A data collector forwards selected audit logs from a host (agent based or host based log streaming into index and aggregation point)
 * A ingest and indexing point aggregation point for correlation and data normalization
 * A search node that is used to for visualization, queries, reports, and alerts (analysis take place on a search node)

Depicted in the image to the right is a basic SIEM architecture.

Operating System Event Logs
Operating Systems

Custom
The structure of the Eventlog key is as follows:

Copy

HKEY_LOCAL_MACHINE

SYSTEM

CurrentControlSet

Services

Eventlog

Application

Security

System

CustomLog Add Windows event log totality of Windows security relevant event

Add Windows totality of Windows application logs

Add Windows totality of Windows system logs

Windows audit logs.

Linux

Add Syslog and audit.d functionality within Linux environment

Operational Use Cases
Operational Use Cases

Handling and operating with SIEM data.

Healthcare as a use case.

Forensics and SIEM.

Attack Modeling.

SIEM repositories.