Considerations for Risk Rating Security Alerts

Security incidents and data breaches are the cybersecurity version of the definition of squares and rectangles in geometry. While all data breaches are security incidents, not all security incidents are data breaches. Before investigating an incident, many security teams know whether the alert will relate to a minor incident or a large-scale breach. Without the ability to distinguish between high risk and low risk alerts, security analysts may spend 32% of their day investigating incidents that pose no real threat.

 

For better threat detection and incident response (TDIR), organizations should consider risk rating security alerts.

What are security incidents?

A security incident is any event that poses a threat to system, network, or data confidentiality, integrity, or availability. A security incident can be anything from a minor service disruption to a large-scale data breach. The National Institute of Standards and Technology (NIST) defines a security incident as an event that:

actually or potentially jeopardizes the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits or that constitutes a violation or imminent threat of violation of security policies, security procedures, or acceptable use policies.

 

In complex, interconnected IT environments, security incident detection becomes increasingly complicated. Organizations adopt security information and event management (SIEM) tools that enable them to aggregate, correlate, contextualize, and analyze data like:

 

Why classifying alerts is difficult

Although every organization is different, effectively classifying alerts into categories helps you prioritize investigation activities. Many organizations classify alerts by the potential business impact a security incident would have.

 

For example, you might want to classify alerts as:

  • Low: minor threats or non-critical issues with little system security impact
  • Medium: potential vulnerabilities or risks with possible security system impact if left unaddressed
  • High: significant system security threat that requires immediate attention and rapid action to mitigate data breach or system compromise risk

 

 

Despite sounding simple, these categorizations are challenging. Cloud technologies can generate terabytes of data every day, making it difficult to separate high severity from medium and low severity data.

 

For example, a company invested in the Microsoft ecosystem that also uses Amazon Web Services may need to aggregate, correlate, and analyze:

 

The more data that the organization collects, the more it needs to rely on security technologies to help risk rate security alerts.

 

Why integrating threat intelligence enhances security alert risk rating

Integrating threat intelligence into security alert risk rating enables the organization to incorporate real-world threat activity into its ongoing monitoring. Threat intelligence feeds give security teams information about:

  • Newly published vulnerabilities
  • Threat actor tactics, techniques, and procedures (TTPs) seen “in the wild”
  • Attacks targeting industry sectors
  • Indicators of Compromise (IoCs) like known malicious IP addresses, domain names, URLs, malware hashes

 

 

With threat intelligence, security teams:

  • Improve alert quality to reduce the number of false positives
  • Add situational context based on real-world activity
  • Improve alert risk rating and prioritization
  • Respond to high-risk incidents faster

 

3 High-Risk Security Events That Should Trigger Alerts

As you begin risk-rating your security alerts, the first step can be identifying events that should always be considered “high risk”.

Ransomware and Other Malware

Endpoint security data can help you monitor for ransomware where. Some data to incorporate in alerts includes:

  • User data
  • Process data
  • File create, read, update, and delete (CRUD) events
  • Registry and services CRUD events
  • Memory
  • Device drivers
  • Disk and network data
  • Metadata, like integrity checks or hash values

Mass Data Move

A mass data move can indicate either an accidental data loss, compromised credentials, or unauthorized access from exploiting a vulnerability. Some data to incorporate in alerts includes:

  • Firewall logs
  • Network traffic
  • Data download limits
  • User access logs

Excessive Failed Login Attempts

Excessive failed login attempts indicate potential brute force attacks or unauthorized access attempts. Some data to incorporate in alerts includes:

  • User access ID
  • Number of failed login attempts
  • Number of successful logins
  • Geolocation of failed logins
  • Geolocation of successful logins
  • Timestamp for failed logins
  • Timestamp for successful logins

Additional Security Alert Risk Considerations

When attempting to improve alert fidelity, you may want to consider incorporating additional signals as part of your risk rating process.

Assets Impacted

High-risk assets typically include:

  • Sensitive data, like personally identifiable information (PII), protected health information (PHI), cardholder data, or intellectual property
  • Applications, networks, and systems that are critical to continued business operations

 

MITRE ATT&CK TTPs

By incorporating threat intelligence, organizations can implement detections, like Sigma rules, that incorporate threat actors TTPs aligned to the ATT&CK Framework. This alignment can help security teams investigate incidents faster by helping identify attack paths.

User and Entity Behavior Analytics (UEBA)

UEBA provides insights into how people typically use resources so that security teams can more rapidly detect anomalous activity that might indicate a potential security incident. For example, abnormal activity from users who access high-risk assets should be assessed at a higher risk rating.

 

API Security

Since APIs enable applications to communicate, you should:

  • Identify all APIs, including managed and unmanaged ones
  • Capture API request and response data
  • Monitor for vulnerabilities or other issues that attackers can use

When considering an API’s risk profile, you should review:

  • The sensitivity of the data traveling across the API
  • The business criticality of the applications that use the API to communicate

 

Graylog: Improving Security Alert Risk Analysis

With Graylog Security, you can use prebuilt content to map security events to MITRE ATT&CK. By combining Sigma rules and MITRE ATT&CK, you can create high-fidelity alerting rules that enable robust threat detection, lightning-fast investigations, and streamlined threat hunting. For example, with Graylog’s security analytics, you can monitor user activity for anomalous behavior indicating a potential security incident. By mapping this activity to the MITRE ATT&CK Framework, you can detect and investigate adversary attempts at using Valid Accounts to gain Initial Access, mitigating risk by isolating compromised accounts earlier in the attack path and reducing impact.

 

Graylog’s risk scoring capabilities enable you to streamline your TDIR by aggregating and correlating the severity of the log message and event definitions with the associated asset, reducing alert fatigue and allowing security teams to focus on high-value, high-risk issues.

 

 

The post Considerations for Risk Rating Security Alerts appeared first on Graylog.