Logging can be the most useful tool in your security arsenal, but it’s something we all tend to overlook and not assign appropriate resources to, as it can use up hard drive storage. Proper logs can provide evidence as to how an incident occurred and what the attacker did.
Too often we don’t keep logs long enough. FireEye indicated that the median dwell time for attackers who use ransomware as their attack tool of choice is 72.75 days. A report on a ransomware attack from last year showed that the attacker lurked in the network for eight weeks before detonating the malware.
Would you have stored log files for eight weeks or more to investigate a lurking attacker? Would we have been able to sift through the log files to quickly identify an attack sequence?
The report recommended a “managed defense service or an equivalent is maintained to detect and respond to incidents on endpoints (i.e., laptops, desktops, servers) to provide protection.” I’d also argue that as part of that process, the service needs to log so that you can have evidence for analysis.
Microsoft Sentinel cloud SIEM
You shouldn’t just log for logging’s sake. Too often an intrusion occurs but no one saw the evidence in the logging tool. Analysis of logging should be part of your solution. A good security information and event management (SIEM) tool can help you manage and review logs. You have many options, including whether the repository will be on a local disk or in a cloud storage.
Microsoft’s cloud SIEM is called Sentinel. As a cloud service, Sentinel’s services are constantly updated. You can track changes in Sentinel by following this site that recaps new releases.
For example, several public previews in January look to bring interesting new features to the platform:
- Support for MITRE ATT&CK techniques
- Codeless data connectors
- Maturity Model for Event Log Management (M-21-31) Solution
- SentinelHealth data table
Also rolled out were:
- More workspaces supported for Multiple Workspace View
- Kusto Query Language (KQL) workbook and tutorial
Mapping MITRE ATT&CK techniques
The support for MITRE ATT&CK techniques maps the information from your logs to attack sequences that have been identified. For example, you can search through the evidence you have stored using Technique 1595, also known as active scanning, where the attacker “may execute active reconnaissance scans to gather information that can be used during targeting. Active scans are those where the adversary probes victim infrastructure via network traffic, as opposed to other forms of reconnaissance that do not involve direct interaction.”
Codeless connectors
Because logging is needed for anything that do these days, Sentinel is previewing the use of codeless connectors that allow logging to be implemented from software-as-a-service (SaaS) platforms to be pulled into Sentinel. Especially as we move more to cloud and Azure applications that communicate with on-premises assets, having tools to pull in that information into logging is key to getting a better view into all your assets that you want to manage and protect.
Meeting OMB event log mandates
The Office of Management and Budget’s (OMB’s) M-21-31 mandates a maturity model for event log management. Four logging levels are set for all government agencies to aim for. The government agencies will receive a ranking ranging from EL0 to EL3. If logging requirements are only partially met by the agency, they will receive a ranking of EL0 or “not effective”. The goal is to raise to EL3 where the logging requirements at all criticality levels are reached.
Sentinel will support collecting these government-mandated event logs:
- Properly formatted and accurate timestamp
- Status code for the event type
- Device identifier (MAC address5 or other unique identifier)
- Session/Transaction ID
- Autonomous system number
- Source IP (IPv4)
- Source IP (IPv6)
- Destination IP (IPv4)
- Destination IP (IPv6)
- Status Code
- Response Time
- Additional headers (i.e., HTTP headers)
- Where appropriate, the username or userID shall be included
- Where appropriate, the command executed shall be included
- Where possible, all data shall be formatted as key-value-pairs allowing for easy extraction
- Where possible, a unique event identifier shall be included for event correlation; a unique event identifier shall be defined per event
SentinelHealth monitors connector health
The SentinelHealth data table helps monitor connector health, providing insights on health drifts such as latest failure events per connector, or connectors with changes from success to failure states.
Support for MSSPs
Managed Security Service Providers (MSSPs) need to monitor more than one activity. Sentinel allows multiple workspace views, which allows an MSSP to review multiple workspaces at the same time, even across tenants.
KQL support
The January release includes Advanced KQL for Microsoft Sentinel interactive workbook, which is designed to help you improve your Kusto Query Language proficiency by taking a use-case-driven approach.
Copyright © 2022 IDG Communications, Inc.
