From company inception, HOOP Cyber have recognised that whilst there is significant market demand for the ability to store and retain security data for longer, the industry hasn’t really solved for how to mine this data sufficiently and for what purpose.

As such, HOOP Cyber are Amazon Security Lake leading partners who are focused on creating optimised data security pipeline for increased data visibility, stored for longer, whilst providing use case driven capability for threat hunting.

We have developed a unique 4 step process for the successful creation and adoption of a Security Lake, including economic use case development, optimisation and prioritisation of data source content.  An important aspect to consider is the chatty nature of some of the data sources (eg. VPC Logs) which can very quickly and very dramatically create large data volumes, which are not only costly to store, but also costly to normalise initially. 

Fortunately, cloud providers (AWS is especially good) will report this cost, as well as providing a 30 day forecast estimate of charges.

Before instantiating the lake, and looking at source publishers, care should be taken around permissions, especially schema authentication and shared logging accounts (this is not uncommon).

Therefore, when planning the lake, we would strongly advise that you take the time to consider your access policies and, crucially, the implementation of these policies within the environment.  This could be as simple as the ability to uniquely access data, as well as write to long term fidelity storage environments and the security lake proper.

In terms of source data, care should be taken to not just consider the criticality of the source, but also the components of what need to stored, how hard it is to access, how hard it is to transform etc.  Certainly, using optimised filtering alone can reduce log size by up to 70%, and this is before Parquet benefits and automated ASL GZIP compression is taken into account.  Furthermore, appropriate categorisation of the data store also needs to be carefully planned, as OCSF v1.1 has deprecated Security Finding into several new categories including Detection, Incident, Compliance and Vulnerability.  HOOP has substantial experience helping and advising customers on correctly mapping and optimising the incoming data stream, working with our partners Cribl.

Once the lake is established, we then focus on use case development for threat hunting, providing sample boilerplate template use case and scripts which are then optimised specifically for the customer’s environment using a mixture of search capability through Athena, OpenSearch, Cribl Search and Query.AI, which takes us to our next section….

So…We’ve got the Security Lake, now what….?

Considerations of OCSF

When determining the use case search, there a number of things to consider beyond optimisation of the search, such as your OCSF normalisation policy and the inspecting of the security lake data holistically.

When scripting for OCSF specifically, we recommend the following:

• Implement data classification to categorise data based on sensitivity for better access control decisions (box plot is helpful).
• Regularly update threat intelligence feeds to stay informed about the latest threats (make sure you integrate the TI feeds so that you can automatically integrate findings into the search).
• Consider user risk scoring based on persona, access attempts, data access patterns, and other factors to prioritise investigations.
• Don’t forget that a complete a complete OCSF compliance strategy will involve additional security measures beyond KQL queries.

Threat Hunting

When considering Threat Hunting, there are a number of areas that can be considered, however the top priorities typically are:

• Investigating Suspicious User Activity
• Hunting for Malware and Intrusions
• Detecting Insider Threats
• Advanced Threat Hunting

However, simply creating standard scripts can have considerable unintended costs, in terms of GET, LIST *… requests, which can search substantial amounts of data very quickly.

This is not only in pure OpenSearch or Athena costs, but also cloud egress charges if you are storing and analysing data across clouds.

Fortunately, cloud providers (such as AWS) provide excellent cost capture and forecasting capabilities, which enables you to determine how long a search took, how much resources were used, which then provides the ability to preferably optimise the search to stay within the “free-tier” of search.

Furthermore, ASL automatically provides an element of partitioning of data, which helps limit the scope of the search.

In addition, HOOP use functions within OpenSeach, Athena, Cribl Search and Query.AI to dramatically improve the efficiency of the search, ensuring that resource allocation is optimised as much as possible.

A more detailed consideration for priority use case threat hunting is as follows:

Investigating suspicious user activity:

• Identifying lateral movement within the network by analysing user logins from unusual locations or times.
• Detecting unauthorised access attempts through failed logins with uncommon usernames or brute-force attacks.
• Uncovering privilege escalation attempts by monitoring user activities beyond their typical permissions.

Hunting for malware and intrusions:

• Analysing network traffic for suspicious file transfers or communication with known malicious domains.
• Correlating system logs to identify indicators of compromise (IOCs) associated with specific malware variants.
• Hunting for anomalies in endpoint behaviour, like unexpected process executions or registry modifications.

Detecting insider threats:

• Monitoring user access to sensitive data and identifying unauthorised downloads or exfiltration attempts.
• Analysing email activity for suspicious attachments, keywords, or communication patterns with external parties.
• Correlating user activity with known insider threat indicators, such as accessing irrelevant data or unusual data deletion attempts.

Advanced threat hunting:

• Identifying unknown threats by analysing historical data for patterns that deviate from normal user behaviour.
• Utilising threat intelligence feeds to enrich security lake data and identify potential attack campaigns.
• Hunting for living-off-the-land (LotL) techniques where attackers misuse legitimate tools for malicious purposes.

Additional use cases:

• Investigating security incidents and identifying the root cause of breaches.
• Identifying vulnerabilities in systems and applications by analysing network traffic and configuration data.
• Monitoring compliance with security policies and regulations by analysing user activity and system configurations.

Suspicious User Activity

When investigating suspicious user activity in a security lake, it is important to focus on fields that provide context around user actions, particularly those that deviate from their normal behaviour. Here are some key fields and values to consider:

User Identification:

• Username:This is the most basic identifier and can reveal unauthorised access attempts if used from unknown accounts.
• IP Address:Track login attempts from unusual locations or a rapid change in IP addresses used by a single user.
• Device ID:This can help identify compromised devices being used for unauthorised access or lateral movement.

Login Activity:

• Timestamp:Look for logins outside of a user’s typical working hours or geo-location.
• Login Attempts:A surge in failed login attempts, especially with uncommon usernames, could indicate brute-force attacks.
• Authentication Method:Unusual authentication methods (e.g., switching from multi-factor to single-factor) could be a sign of compromised credentials.

User Actions:

• File Access:Monitor access to sensitive data, especially downloads or attempted exfiltration of large datasets.
• Application Usage:Identify activity in applications a user doesn’t normally use or unexpected actions within authorised applications.
• System Commands:Unusual system commands could indicate attempts to escalate privileges or install malware.

Additional Considerations:

• Baseline Behaviour:Compare user activity to established baselines to identify significant deviations.
• Peer Group Analysis:Analyse activity against similar user groups to identify anomalies within a specific role.
• Alert Enrichment:Use threat intelligence feeds to enrich your data and identify suspicious activities linked to known malware or attack campaigns.

 

Values to Search For:

Beyond specific fields, there are also values to look out for that might indicate suspicious activity:

• “Unknown” or “Not Recognised” valuesin any of the mentioned fields (username, IP address, device ID).
• Privileged accountsaccessing unusual data or performing unauthorised actions.
• Rapid succession of eventssuch as login attempts, file downloads, or system commands outside the user’s typical behavior.

Investigating Suspicious User Activity (AC-2, AC-6), sample KQL (aligned to OCSF) :

// Include user roles and entitlements for context

SigninLogs

| where Timestamp > ago(7d)

| join kind=inner (UserRoleAssignments) on Username

| where (

    // Look for logins from unknown locations

    Location =~ ‘Unknown’

    or

    // Or a significant deviation from usual location

    Location != tostring(user_location(Username))

)

| where FailureReason != ‘AccountNotFound’ // Exclude “Account not found” errors

| where Role not in (allowed_roles(DataLocation)) // Limit access based on data location and role

| project Username, Role, Location, Timestamp, FailureReason

| sort by Timestamp desc

// Additionally, investigate users with multiple failed login attempts

SigninLogs

| where Timestamp > ago(7d)

| where FailureReason == ‘IncorrectPassword’

| group by Username

| summarize count(*) by Username

| where count(*) > 5 // Threshold for suspicious failed login attempts

| project Username, count(*) as FailedLoginAttempts

| sort by FailedLoginAttempts desc

Summary:

This script incorporates user roles retrieved from the UserRoleAssignments table. It restricts access based on allowed_roles function (replace with your permissioning schema) ensuring users only access data permitted by their roles.

This script leverages two tables:

• SigninLogs:This table should contain user login attempts with data points like Username, Location, Timestamp, and FailureReason.
• user_location(Username):This is a user-defined function that retrieves a user’s typical location based on past login attempts. You’ll need to replace this with the actual function in your environment.

Explanation of the Script:

Filter Timeframe:The script first filters SigninLogs for the past 7 days (adjust this timeframe as needed).

1. Suspicious Locations:It then searches for logins with either “Unknown” location or a location significantly different from the user’s typical location (determined by the user_location function).
2. Exclude Account Not Found Errors:This excludes entries where the account simply doesn’t exist, focusing on potential unauthorised attempts.
3. Failed Login Attempts:The second part looks for users with more than 5 failed login attempts within the timeframe, indicating brute-force attacks or stolen credentials.

Note: This is a basic example. You can customise it further by:

• Including additional filters like IP address or device ID.
• Correlating login activity with user actions (e.g., data access) for a more comprehensive investigation.
• Integrating threat intelligence feeds to identify suspicious usernames or IP addresses (we would recommend streaming your Recorded Future threat intelligence to your security lake, so that you automatically correlate across both sources).
• Adapt this script to your specific data schema and security requirements.
• Finally, don’t forget these scripts provide a foundation for investigation aligned with OCSF principles and are samples only

Malware and Intrusions

Network Traffic Analysis:

• Source and Destination IP Addresses:Look for unusual communication with known malicious domains or suspicious traffic patterns.
• Port Numbers:Certain ports are commonly used for malware communication (e.g., port 443 for encrypted traffic).
• File Hashes:Compare file hashes against known malware signatures to identify potential infections.
• Protocol Used:Unusual protocols or a sudden shift from standard protocols (e.g., HTTP) could indicate malware activity.
• Packet Size and Frequency:A surge in unusually large data packets or a high frequency of communication can be signs of malware exfiltrating data.

 System Logs:

• Event Type:Focus on errors or warnings related to failed program executions, suspicious file modifications, or security software alerts.
• User Involved:Identify user accounts associated with suspicious events, especially privileged accounts.
• Source Application:Investigate logs related to applications known to be vulnerable to malware exploitation.
• Timestamps:Correlate timestamps across various logs to identify potential timelines of intrusion attempts.

Indicators of Compromise (IOCs):

• URLs:Search for URLs associated with known malware distribution or phishing campaigns.
• File Names:Look for file names with extensions commonly used by malware (e.g., .exe, .scr).
• Registry Keys:Malware often creates specific registry keys to maintain persistence. Utilise threat intelligence feeds for the latest IOCs.

Values to Search For:

• “Blocked” or “Failed” eventsin security software logs, indicating potential malware being stopped.
• Unknown or suspicious file namesbeing accessed or executed by system processes.
• Changes to system configurationsuch as new firewall rules or disabled security software.
• Communication with known malicious IP addresses or domains.

Investigating Malware and Intrusions (NSM-3, NSM-7), sample KQL (aligned to OCSF):

// Leverage threat intelligence for malicious IPs

SigninLogs

| where Timestamp > ago(7d)

| where RemoteIP in (threat_intelligence(‘malicious_ips’))

| project Timestamp, SourceIP, RemoteIP, DestinationPort, Protocol

| sort by Timestamp desc

// Investigate potential malware execution attempts and suspicious file hashes

SystemEvents

| where Timestamp > ago(7d)

| where EventLevel == ‘Error’

| where Message =~ ‘access denied’ or Message =~ ‘failed to execute’

| project Timestamp, Source, EventID, Message

| sort by Timestamp desc

FileEvents

| where Timestamp > ago(7d)

| where Action == ‘Created’ or Action == ‘Downloaded’

| where SHA256 not in (known_good_hashes()) // Replace with known good hash function

| join kind=inner (ThreatIntelligence) on SHA256 // Enrich with threat intel

| project Timestamp, Filename, SHA256, ThreatIntelligence.ThreatName

| sort by Timestamp desc

Summary:

This script utilises threat intelligence feeds to identify malicious IP addresses and enrich file information with potential threat classifications.

This script assumes you have the following tables:

• SigninLogs: This table should contain network traffic data with information like Timestamp, SourceIP, RemoteIP, DestinationPort, and Protocol.
• SystemEvents: This table should include system event logs with Timestamp, Source (application or service), EventID, and Message fields.
• FileEvents: This table should contain file activity data with Timestamp, Filename, Action (created, downloaded, etc.), and SHA256 hash of the file.

Explanation of the Script:

1. Malicious Network Traffic: The first part searches for network traffic events within the last 7 days (adjustable) that originate from known malicious IPs (obtained from a threat intelligence feed) or use uncommon destination ports.
2. Failed Executions: It then investigates system events marked as errors within the timeframe, focusing on messages indicating “access denied” or “failed to execute” which could be related to malware blocked by security software.
3. Suspicious File Hashes: The last part identifies newly created or downloaded files whose SHA256 hash doesn’t match a list of known good hashes (replace with the appropriate function for your environment). This can indicate potential malware dropped on the system.

Important Considerations:

• This script provides a starting point. You can customise it further by including additional filters based on your environment (e.g., specific applications or file types).
• Threat intelligence feeds are crucial for keeping the “malicious_ips” list updated.
• Incorporate additional data sources like process execution logs for a more comprehensive investigation.
• Adapt this script to your specific data schema and security needs.
• Finally, don’t forget these scripts provide a foundation for investigation aligned with OCSF principles and are samples only

Insider Threats

When it comes to detecting insider threats within a security lake, the focus shifts to identifying unusual patterns in user activity that could signal malicious intent. Here’s what you should look for:

Data Access and Exfiltration:

• Files Accessed: Monitor access to sensitive data, especially downloads of large datasets or frequent access to irrelevant information.
• Data Transfer Methods: Look for unusual data transfer methods like external drives, cloud storage usage, or unexpected printing activity.
• File Deletion: Focus on attempts to delete large amounts of data, particularly around critical projects or after hours.
• Search Queries: Analyse user search queries for keywords related to sensitive data or exfiltration techniques.

 

Email Activity:

• Recipients: Monitor emails sent to external addresses, especially those containing sensitive data or large attachments.
• Email Content: Look for keywords or phrases that might indicate attempts to gather confidential information or share it with unauthorised parties.
• Unusual Sending Times: Emails sent outside of regular work hours, especially from personal accounts, could be a red flag.
• Large Attachment Sizes: Monitor emails with unusually large attachments, especially if sent to external recipients.

User Behaviour Analysis:

• Session Duration and Frequency: Analyse deviations from typical login patterns, like extended sessions outside of work hours or frequent login attempts from unusual locations.
• Application Usage: Identify activity in unauthorised applications or unexpected actions within authorised ones, particularly those with access to sensitive data.
• System Commands: Unusual system commands could indicate attempts to escalate privileges, install unauthorised software, or tamper with system configurations.

Values to Search For:

• Access to highly sensitive data by users who wouldn’t normally require it for their job functions.
• Data transfers to external recipients without proper authorisation or following unusual protocols.
• Deletion attempts of critical data especially around times of potential discontent or disciplinary action.
• Communication with known suspicious email addresses or frequent exchanges with external parties about confidential information.

Detecting Insider Threats (ITM-2, ITM-3), sample KQL (aligned to OCSF):

// Investigate user access to sensitive data

UserActivity

| where Timestamp > ago(7d)

| where ActionType == ‘Access’

| where DataSensitivity == ‘High’

| where Username not in (data_owners(DataLocation)) // Exclude data owner access

| project Username, DataLocation, Timestamp, ActionType

| sort by Timestamp desc

// Analyse user email activity for suspicious patterns

UserEmails

| where Timestamp > ago(7d)

| where (

    RecipientDomain not in (allowed_domains())  // Replace with allowed domains list

    or

    AttachmentsSize > 100MB // Adjust threshold for suspicious attachment size

)

| project SenderUsername, RecipientDomain, AttachmentsSize, Timestamp

| sort by Timestamp desc

// Identify deleted data events and potentially suspicious timing

DataDeletionEvents

| where Timestamp > ago(7d)

| where DataSensitivity == ‘High’

| project Username, DataLocation, Timestamp

| sort by Timestamp desc

// Look for unusual login activity patterns

SigninLogs

| where Timestamp > ago(7d)

| where (

    // Access from unexpected locations

    Location =~ ‘Unknown’

    or

    Location != tostring(user_location(Username))

)

| where Timestamp > outside_of_work_hours() // Define function for non-work hours

| project Username, Location, Timestamp

| sort by Timestamp desc

Background:

This script incorporates a user baseline activity table (UserBaselineActivity) to compare current data access with typical historical patterns for that user. This can help identify anomalous access attempts.

This script assumes you have the following tables:

• UserActivity: This table should contain user activity logs with fields like Username, DataLocation, Timestamp, and ActionType (e.g., access, download).
• data_owners(DataLocation): This is a user-defined function that retrieves the designated owners for a specific data location.
• UserEmails: This table should include user email activity data with SenderUsername, RecipientDomain, AttachmentsSize, and Timestamp.
• allowed_domains(): This is a user-defined function that specifies a list of authorised email domains for outgoing communication.
• DataDeletionEvents: This table should contain logs related to data deletion events, including Username, DataLocation, and Timestamp.
• SigninLogs: This table should contain user login attempts with Username, Location, and Timestamp.
• outside_of_work_hours(): This is a user-defined function that identifies timestamps falling outside of standard work hours in your organisation.

Explanation of the Script:

1. Data Access: The first part focuses on user access to highly sensitive data (DataSensitivity == ‘High’) within the last 7 days. It excludes data owners (retrieved by the data_owners function) to concentrate on unauthorised access attempts.
2. Suspicious Emails: It then investigates emails sent to external domains not on an approved list (defined by the allowed_domains function) or emails with unusually large attachments.
3. Data Deletion Events: This section identifies deletions of sensitive data, which could be malicious if done by unauthorised users or at suspicious times.
4. Unusual Login Activity: The final part looks for login attempts from unknown locations or outside of regular work hours (identified by the outside_of_work_hours function), which could be signs of potential insider activity.

Important Notes:

• This script provides a foundation, and you can customise it further based on your environment.
• Ensure the data_owners function and allowed_domains function are tailored to your specific data ownership structure and authorised email recipients.
• You can expand this script by incorporating additional data sources like user searches or downloaded files for a more holistic investigation.
• Adapt this script to your specific data schema and security requirements.
• Remember, adapt this script to your specific data schema and security needs.

Beyond Proactive Threat Hunting

Incident Alerting

Whilst it is noted that the Security Lake could in no way be considered a SIEM, customers require the ability for high severity events be alerted and flagged into an event manager for further inspection.  HOOP Cyber has a developed a couple of approaches to tackle this issue, which is a mixture of real-time alerting and subsequent batch processing.

Simulated Logs

It is also noted that customers may want to inject simulated logs into the lake for the testing and verification of script and associated alerting and reporting.  There are a number of techniques that can be applied here, specific to data generation, anonymised actual data and simulated synthesised data streams.

OCSF Mapping

We have also seen that the mapping of source data into OCSF format is somewhat haphazard and requires some work to standardise this.  For example, some data appears to be mapped to the unknown field which brings its own challenges.  HOOP will be publishing a list of known OCSF maps and will be making recommendations on how best to map data in a more standardised fashion.

Search

Finally, from a search perspective, whilst some use case examples exist (and HOOP have documented), these generally are source specific.  The real value of a security lake is ability to search holistically across all relevant data sources, and HOOP has given considerable thought to this.  This, critically, is why consistent OCSF mapping is absolutely vital.

These will be topics for future Blog series.

Summary

This blog has hopefully provided a primer as to considerations for your Security Lake switch-on, and food for thought around source ingest, as well as lightweight efficient search and long-term fidelity storage.

If you are like many customers that are frustrated with the limited data visibility within your SIEM and are looking to increase your data value and retention time, whilst lowering your tangible operating costs (including licensing and infrastructure) HOOP Cyber would love to hear from you.

We strongly believe that not only can HOOP Cyber ensure that we can simplify the instantiation and adoption of your security lake, we can also help extract maximum economic value through the optimisation and prioritisation of data sources, the provision use case driven (lightweight) threat hunting capability, and the optimisation of subscriber destinations and offline storage.