When Amazon Web Services (AWS) initially launched in 2006, it offered the first compute, storage, and database cloud service that developers could build on. Over time, AWS became a fundamental cloud service provider as organizations started migrating to the cloud.

As one of the three primary cloud services providers, AWS remains integral to most businesses. With organizations deploying more cloud-native applications and running more workloads in the cloud, managing AWS security has become increasingly important to your business. While AWS manages the infrastructure’s security, you still need to manage security within your AWS environment.

To protect sensitive data and applications, you need a comprehensive AWS cloud security strategy.

What is AWS Cloud Security?

AWS cloud security is a framework designed to mitigate risk and protect the cloud-based infrastructure. Under the Shared Responsibility Model, AWS manages the security of the cloud infrastructure while customers secure the activities within the cloud. AWS provides a suite of tools and services that help organizations implement and monitor key security requirements, like:

• Identity and access management (IAM): authorizing and authenticating users and services
• Vulnerability management: detecting and remediating security weaknesses
• Encryption: transforming information so that only authorized parties can understand it
• Continuous monitoring: setting alerts to detect abnormal activity indicating a potential security incident

The suite of tools supports compliance requirements and identifies suspicious behavior within cloud environments so that security teams can understand and rapidly respond to any potential security issues.

How Does AWS Security Work?

AWS provides customizable security tools to help you implement and adapt your security measures. While AWS maintains the infrastructure layer’s security, you need to manage all other aspects.

Securing the AWS Infrastructure

Although AWS maintains the security of its cloud infrastructure, you will still be responsible for configuring security measures on top of that secure cloud infrastructure. AWS infrastructure security includes:

• Data protection: encryption for data-at-rest and access restriction policies
• Continuous monitoring: threat identification and event logging
• Compliance: on-demand access to compliance reports

Securing Applications on AWS

Since you’re responsible for securing what happens in your AWS infrastructure, you need to implement security controls, like:

• Threat detection: identify threats and reduce false positives
• Web application security: block common attacks and tackle application security needs with a web application firewall
• Automation: adapt to operational contexts with automated security incident response tools
• Proactive monitoring: event logging to identify potential security issues

Securing Data on AWS

AWS offers you capabilities that help protect sensitive data, including:

• Encryption: AES-256 for data-at-rest in services like Elastic Block Store (EBS), Simple Storage Service (S3), Relational Database Service (RDS), and Redshift
• Key management: key management and data discovery tools
• Data Protection: S3 inventory and bucket monitoring
• Compliance: automated compliance checks
• Data redundancy: data duplication and monitoring

What Security Tools Does AWS Offer?

AWS offers products and services to help you manage your security responsibility. Some key tools include:

• AWS IAM: manages permissions to control what AWS resources users can access
• Amazon GuardDuty: analyzes logs from CloudTrail, VPC Flow Logs, and DNS to identify threats like privilege escalation and compromised credentials
• AWS Config: records configuration changes across AWS resources with notification and the ability to enable automatic remediation
• AWS Inspector: assesses network vulnerabilities and generates security finding to prioritize vulnerability remediation efforts
• AWS CloudTrail: records AWS API calls for auditing and compliance tracking with comprehensive user activity and API usage monitoring
• AWS CloudWatch: centralized logging and monitoring for AWS environments to detect abnormal behavior and unauthorized activity
• AWS Shield: guards against network and transport layer Distributed Denial of Service (DDoS) threats

Why Do Organizations Struggle with AWS Cloud Security?

While many companies use AWS services, they use more than just AWS services. Managing security across a multi-cloud or hybrid environment that includes on-premises resources makes security complex. Some common challenges include:

• Identifying assets: Cloud environments change quickly and keeping up-to-date becomes overwhelming, especially with short-term assets like virtual machines
• Maintaining secure configurations: Configuration drift can occur when adding new applications or responding to access requests, creating security gaps.
• Securing APIs: Attackers can use misconfigurations or vulnerabilities to gain unauthorized access to applications and data.
• Enforcing access controls: Changes to user access controls at the network and application layer can lead to excess privileges and unauthorized access.
• Visibility across environment: Using only AWS provided security tools can limit visibility into risks from other cloud providers or the on-premises deployments.

Best Practices for Implementing AWS Cloud Security with a Threat Detection and Incident Response Solution

Your AWS cloud security needs to be integrated into your overarching security monitoring function. If you’re busy trying to monitor different cloud environments, like AWS and Azure, in the vendor-supplied tools, you can miss key alerts because you have no way to correlate the data. Meanwhile, if you have an on-premises deployment, like a data center, that connects to your AWS cloud, you need to correlate that data, too.

Some best practices for implementing holistic AWS cloud security include:

• Enforce the principle of least privilege: Users and services should have only the access they need to function, and privileges should be consistently enforced across the entire IT environment.
• Limit AWS security groups: AWS security groups manage incoming and outgoing traffic for Elastic Compute Cloud (EC2) instances and should be limited to permit only necessary traffic.
• Encrypt data-at-rest and in-transit: AWS’s built in encryption manages data-at-rest, but you should ensure that you enable it for all services. You also need to encrypt your networks to protect data-in-transit.
• Limit communications between resources: You should consider having inbound and outbound firewalls that manage communications across internal networks as well as from external sources.
• Centralize all log data: Combining all cloud and on-premises log data enables you to gain visibility into all activities occurring across multi-cloud and hybrid environments.
• Correlate on-premises and cloud logs: Comprehensive log monitoring across both AWS and on-premises environments enables you to correlate data for insights into potential threats and improve alert fidelity.
• Monitor API security: A web application firewall (WAF) combined with an API security solution that captures unfiltered API request and response details helps you detect attacks or API failures.
• Map controls to compliance requirements: Aligning security activities with the compliance requirements that your business needs to meet will help you provide assurance over your cloud security posture for senior leadership and customers.

Graylog: Threat Detection and Incident Response For AWS or Multi-Cloud Monitoring

With Graylog’s AWS Kinesis/CloudWatch input you can centralize all your AWS VPC Flow Logs and any other provider flow logs for a single source of network traffic truth across your cloud, multi-cloud, or hybrid infrastructure.

Graylog ingests all log data, no matter what service generates it, then applies a standardized data model so that you can correlate and analyze all events. Since your IT operations and security teams share the same information, they can communicate more effectively.

Further, with Graylog’s lightning-fast search capabilities, your security and IT teams can get the answers they need, even when they’re searching terabytes of data. Purpose-built for modern log analytics, Graylog gives you the two-for-one solution necessary to improve performance and reduce cybersecurity risk. Our cloud-native capabilities and out-of-the-box security content give your teams the ability to collaborate effectively, reducing service downtime and alert fatigue.

To learn how Graylog can help you save money and respond more effectively to issues,  contact us today.

For many Security Operations Center (SOC) teams, every day feels like a balancing act just shy of burnout. The alerts don’t stop. The tooling gets in the way more than it helps. And analysts—the people at the heart of security operations—are left trying to untangle signals in a sea of noise, pressure, and constant escalation.

This isn’t just a tooling issue. It’s a deeper misalignment: the gap between what SIEM was supposed to be and what security teams actually need.

The opportunity isn’t to throw more dashboards at the problem. It’s to realign the system around defenders—prioritizing clarity over clutter, response over noise, and design that works with human workflows, not against them.

That’s what it looks like when SIEM is built for outcomes, not overhead. And that’s the direction modern security operations are finally moving toward.

The SIEM Status Quo Isn’t Just Unsustainable. It’s Holding Teams Back.

SOC teams aren’t imagining the pressure. According to the VikingCloud 2025 Cyber Threat Report:

• 33% of organizations said false positives delayed real incident response
• 63% of teams spend over 4 hours per week triaging alerts
• 15% spend more than 7 hours weekly chasing false alarms

This isn’t just alert fatigue—it’s resource erosion. Security teams spend hundreds of hours a year on signal-to-noise problems that their tools should already solve.

What makes this worse? The economics of legacy SIEMs. Many vendors tie costs to ingestion volume, forcing teams to make painful trade-offs. DNS, DHCP, API telemetry—all crucial for threat detection—often get left out to keep costs predictable.

According to the SANS 2024 SOC Survey, only 38% of organizations send all logs to their SIEM. The rest operate with incomplete data and in complete confidence.

A Smarter Approach: Built for the Realities of the Modern SOC

Graylog Security is designed for today’s operational complexity. It doesn’t ask security teams to compromise—it helps them evolve.

Clarity Over Noise

• Risk-based alerts tuned to reduce false positives
• API security monitoring to detect PII leaks and data exfiltration
• MITRE ATT&CK mapping to track detection coverage and gaps
• Exposure-aware prioritization to elevate threats that matter

This isn’t alerting for alerting’s sake. It’s focused visibility that supports faster decisions and better outcomes.

Flexibility Without Surprise Costs

Security teams deserve control over both their visibility and their budgets. Graylog offers:

• Data Routing to separate critical from archival logs
• Tiered storage with hot, warm, and archive options
• Selective data retrieval from lakes to reduce noise and cost
• Transparent pricing to support long-term planning

“The cost-to-performance ratio is unmatched. We now ingest more logs for better coverage without blowing our budget.”
— Gartner Peer Reviewer

Efficiency Where It Counts: Detection Through Response

• Sigma Rules + anomaly detection for smarter detections
• Investigation timelines to unify evidence into clear narratives
• Role-based collaboration to include IT, compliance, and leadership
• GenAI-powered reporting to reduce analyst workload without increasing risk

This is SIEM that accelerates—not complicates—security operations.

More Teams Are Switching—and Staying

Security leaders who rethink their SIEM strategy are finding clarity, confidence, and cost control with Graylog. As we highlight in “Why Security Teams Are Switching to Graylog”, customers choose us for:

• Predictable pricing aligned with usage, not just volume
• Analyst-friendly features and workflows
• Rapid deployment with strong support
• Measurable outcomes across threat detection, investigation, and compliance

“Graylog delivers what our team needs—without the overhead. It just works.”
— Gartner Peer Reviewer

Security That Works with You

Security operations teams don’t need more noise—they need sharper tools that actually reduce it. Graylog Security helps analysts move faster, make more of the data they already have, and stay ahead of threats and burnout.

It’s not just another SIEM. It’s a platform designed to work as hard as your team does.

Download “Fixing SIEM Fatigue – A Practical Guide to Smarter Security Ops” to cut through the clutter, keep costs in check, and build a stronger SOC—one step at a time.

Think back to being in high school and wanting to leave the room during class. Your teacher would give you a hall pass to show anyone monitoring the halls that you had permission to walk around. Your behavior, walking around during the class period, was suspect unless you followed the rule, getting a hall pass.

For security teams, rule-based intrusion detections are the hall monitors that look for behaviors that indicate a problem. Rule-based intrusion detection systems (IDS) use specific rules to identify harmful activities and behaviors, enabling security teams to detect and respond to threats. While they offer various benefits, they also create challenges as security teams need to maintain the rules in an ever-changing threat landscape.

Adding context to rule-based intrusion detections enables security teams to create high-fidelity alerts, reducing false positives and alert fatigue.

What is a rule-based intrusion detection system?

A rule-based intrusion detection system (IDS) identifies malicious activities or unauthorized access by comparing real network traffic against a predefined rule or signature. The rules identify patterns or behaviors associated with security threats, typically based on known attack vectors or published vulnerabilities.

The IDS triggers an alert or takes action when an activity matches rule, enabling security teams to automatically block specific traffic or receive an alert about a potential security incident. Some key features of rule-based IDS include:

• Predefined rules: comparing network traffic to known threat patterns
• Real-time detection: triggering alerts when current network traffic matches the rules
• Response actions: blocking traffic to prevent continued activity or logging the event for later forensic investigation
• Rule management: applying active rules while storing inactive ones

What is the difference between rule-based, signature-based, and anomaly-based IDS?

Three basic types of IDS exist:

• Rule-based: predefined rules to look for policy violations using patterns learned from training data which is valuable for rapidly detecting known threats.
• Signature-based: predefined patterns that match known threats which is valuable for identifying document threats but less effective against new, unknown attacks because it relies on its database.
• Anomaly-based: established baseline for normal network activity that flags significant deviations as suspicious activity or new attacks which may help identify zero-day attacks but can lead to false positives.

What are the benefits of rule-based detections?

Rule-based intrusion detection provides a structured approach to spotting and managing malicious activities, enabling security teams to improve network security. Some of the primary benefits that these rule-based detections provide include:

• Flexibility: giving security teams the ability to enable or disable rules to respond to varying security needs
• Precision: using “if, then” statements to analyze data and identifying potential threats, increasing detection accuracy
• Error management: disabling or ignoring problematic rules when verifying them to reduce errors also reduces false positives and false negatives
• Adaptability: customizing rule sets and regularly updating them for faster responses to newly identified threats and zero days

What are the challenges of using rule-based detections?

Rule-based detections work well for known threats, but they often create challenges when security teams only rely on them to detect incidents. Some primary challenges include:

• Limited capabilities: failure to identify novel or sophisticated attacks, like zero days, that are outside the existing rule set
• Overload of events: high volumes of network traffic triggering excessive event notification that overwhelm security teams and add to alert fatigue
• Errors in rules: duplicated rules or outdated rules leaving threats undetected, increasing data breach risks
• Reliance on rule quality: detection rates and effectiveness dependent on security team’s ability to write clear rules
• Continued maintenance: regular updates and refinements to adapt to new threats and prevent false positive, false negative, and false alarm risks

How does adding context improve rule-based detections?

Adding context to rule-based detections by enriching data can improve accuracy, enabling security teams to more effectively and efficiently protect systems. Context-aware detections enable security teams to improve detections by providing insight into entity behavior and potential impact of the behaviors.

With rule-based detections that use enriched data, security teams can:

• Understand contextual risk in real-time
• Reduce time spent engaging in alert triage
• Filter out low-risk threats and alerts, like testing activity in an environment without sensitive data

For example, adding context to detections may include information like:

• Log message severity
• Event priority based on event definitions or anomaly type
• Assets priority, like business critical applications and databases
• Asset vulnerabilities that impact its risk level

What are the best practices for building high-fidelity rule-based detections?

Building high-fidelity rule-based detections requires careful planning and execution to effectively identify malicious activities. By implementing the following best practices, security teams can improve detection rules in ways that reduce false positives and false negatives.

Centralize and Normalize All Security Data

Capturing the log and event data related to your environment is the basic building block of all detections. To optimize this security data, you need to aggregate it in a central location and normalize the data. The data normalization process converts and standardizes the log formats so that you can compare activities across different technologies.

Identify Use Cases

Identifying use cases helps you determine the types of detections that matter most to your organization’s security. Your use cases define the specific scenarios and threats that you want detections to identify based on your network topology and the typical activities occurring within your environment. For example, some use cases for detections might include:

• Credential stuffing attacks
• Cross-site scripting attacks
• Distributed Denial of Service (DDoS) attack

Build Detections

Building detections involves crafting precise rules that identify network anomalies and potential threats. For example, Sigma rules are a collection of “search scripts” that allows you to identify specific threats by matching log events with potential suspicious activity. Your detections should consider the different logsource components necessary to ensure comprehensive coverage.

Correlate Detections

Correlating detections improves their accuracy and reliability by linking together multiple events. For example, Sigma Correlation rules allow you to build on the basic Sigma rule and define relationships between events. By doing this, you can identify complex threats that might not be detected when looking at isolated events. Effective correlation ensures that suspicious patterns are flagged across different network segments, users, or applications for faster incident detection and investigation.

Add Context to Alerts

Adding context to alerts allows you to better understand the threat and potential impact better. For example, mapping Sigma rules to the MITRE ATT&CK Framework enables you to create tactical alerts for known threats related to your IT environment and engage in proactive threat hunting by leveraging threat intelligence.

Incorporate Risk Scoring

Risk scoring allows you to prioritize the detections so that you can respond to the most critical threats first. Assigning risk scores to the different assets and events enhances decision-making so that you can mitigate a security incident’s impact faster. Some things to consider when creating risk scores include:

• Asset risk, like criticality and known vulnerabilities
• Event risk, like message severity, event priority, and asset priority

Graylog Security: High-fidelity alerts that improve threat detection and incident response

Using Graylog Security, you can rapidly mature your threat detection and incident response capabilities. Graylog Security’s Illuminate bundles include rulesets with content that includes Sigma detections, enabling you to uplevel your monitoring by incorporating threat hunting capabilities and correlations to ATT&CK TTPs.

By leveraging our cloud-native capabilities and out-of-the-box content, you gain immediate value from your logs. Our anomaly detection ML improves over time without manual tuning, adapting rapidly to new data sets, organizational priorities, and custom use cases so that you can automate key user and entity access monitoring.

With our intuitive user interface, you can rapidly investigate alerts. Our lightning-fast search capabilities enable you to search terabytes of data in milliseconds, reducing dwell times and shrinking investigations by hours, days, and weeks.

To learn how Graylog Security can help you implement robust threat detection and response, contact us today.

If you have ever built a LEGO set, then you have a general idea of how telemetry works. Telemetry starts with individual data points, just like your LEGO build starts with a box of bricks. In complex IT environments, your security telemetry is spread across different technologies and monitoring tools, just like in a large build your LEGO bricks come separated into smaller, individually numbered bags. In both cases, the individual bricks or data points aren’t special. However, as you follow the LEGO instructions or incorporate analytics into your monitoring, the individual pieces combine to form the overall structure you need.

By understanding what telemetry is and how to use it for security, IT and security teams can use the data that their environments generate to create proactive security programs.

What is telemetry?

Telemetry is the science of measuring something, transmitting the results to a remote location, and then interpreting the results. In cybersecurity, telemetry refers to the security data that an organization’s systems, networks, applications, and devices generate. Security telemetry is often derived from log data, the information technologies create about activities impacting them.

Security telemetry comes from IT and cybersecurity technologies across the environment, including:

• Web applications and application programming interfaces (APIs), like user and performance data
• Network devices, like routers and firewalls
• Identity and access management (IAM) tools
• Databases, including on-premises and cloud locations
• Workstations and mobile devices, like laptops, smartphones, and tablets

Why is telemetry important?

On its own, telemetry is nothing more than raw data. When you collect, parse, normalize, aggregate, and analyze telemetry, the whole becomes greater than the sum of its individual parts. Telemetry enables IT and security teams to improve:

• Performance and efficiency: using analytics for proactive identification of security vulnerabilities or prediction of system maintenance activities
• Risk management: monitoring for security or operational abnormalities that can lead to business interruption and service outages
• Decision-making: using insights to understand current security and operations posture to find areas of improvement and determine future investments
• Threat hunting: aggregating data points to identify indicators of compromise (IoC’s) that could detect potential advanced persistent threats (APTs) hiding in systems
• Compliance: aggregating and analyzing data to document and report on whether controls function as intended

What are the types of security telemetry?

Security telemetry refers to the continuous monitoring and analysis of security events within information systems. By collecting detailed information on network traffic, user activities, and system logs, security telemetry enables you to create baselines that define normal behaviors and alert you to anomalous activities that might indicate a potential security incident.

Network Telemetry

Network telemetry helps your network monitoring by aggregating data from sources like:

• Firewalls and Next-Generation Firewalls (NGFW)
• Routers
• Switches
• DNS and Domain Name servers

These technologies generate data that provides insight into:

• Traffic patterns: inbound and outbound communications
• Latency: request and response times
• Usage: resources and ports accessed
• Health: CPU and memory use and device uptime

Endpoint Telemetry

Endpoint telemetry helps you manage devices by aggregating data from sources like:

• Workstations
• Servers
• Mobile Device Management (MDM)
• Endpoint detection and response (EDR)
• Antivirus and antimalware tools
• Vulnerability scanners

These technologies generate data that provides insight into:

• Configurations: updated settings that limit unnecessary functionality
• Vulnerabilities: known security issues that require installation of updates
• Anomalous behavior: programs running that might indicate malware infection

Application Telemetry

Application telemetry provides insights about web applications and their connected APIs by aggregating data from sources like:

• Applications and their servers
• Web Application Firewalls (WAF)
• API Gateways
• IAM tools
• Network devices
• API security tools

These technologies generate data that provides insight into:

• User access: who authenticates into applications and whether their access is limited to only what they need for completing job functions
• Credential-based attacks: identification of failed user logins indicating potential security incidents, like credential stuffing attacks
• API vulnerabilities: security weaknesses, like the ones listed in the OWASP API Security Top 10 list
• API attacks: malicious activity targeting API vulnerabilities

Cloud Telemetry

Cloud telemetry provides insights into system performance, resource utilization, and application health by aggregating data from sources like:

• AWS CloudWatch
• Azure Monitor
• VPC flow logs
• Firewalls

These technologies generate data that provides insight into:

• Misconfigurations: settings that attackers can exploit to achieve their objectives
• Resource and usage costs: memory, CPU, and execution times to understand resource allocation, scaling, and optimization
• Reliability: application’s design and architecture to maintain availability
• Performance: bottlenecks, latency issues, or resource constraints
• Vulnerabilities: programming errors that create exploitable weaknesses

Why is security telemetry challenging?

Many companies struggle to manage and correlate security telemetry because their technologies generate overwhelming amounts of data.

High Storage Costs

The high volumes of data that your environment generates can become prohibitively expensive. Many organizations struggle with high-security information and event management (SIEM) costs, especially as they adopt more cloud-native technologies that generate more data. However, you likely need to retain some data to meet compliance and retention requirements. This can leave you struggling to find multiple storage locations.

Data Ingestion Decisions

Additionally, all data is not equally valuable. For example, you may need packet data for a forensics investigation but not your everyday monitoring. The high storage costs often mean you have to make difficult decisions around the data you send to your security solution. You may need to make difficult decisions about the data that you forward to your security monitoring solution which could create blind spots.

Different Log Formats

Logs don’t have a standard format, creating challenges when correlating security telemetry to gain insights. Some examples of log formats include:

• Windows event logs: Microsoft’s proprietary format
• javaScript Object Notation (JSON): highly readable format, often used for structured logging
• Common Event Format (CEF): text-based, extensible open logging and auditing format

To correlate the data that your technologies generate, you need to parse and normalize the logs before you can correlate and analyze them.

Graylog for Security and Operations: Using Telemetry and Managing Data Effectively

Graylog ensures scalability as your data grows to reduce total cost of ownership (TCO). Our platform’s innovative data tiering and data pipeline management capability facilitates efficient data storage management by automatically organizing data to optimize access and minimize costs without compromising performance.

With frequently accessed data kept on high-performance systems and less active data in more cost-effective storage solutions, you can leverage Graylog Security’s built-in content to uplevel your threat detection and response (TDIR) processes. Our solution combines MITRE ATT&CK’s knowledge base of adversary behavior and vendor-agnostic sigma rules so you can rapidly respond to incidents, improving key cybersecurity metrics. By combining the power of MITRE ATT&CK and sigma rules, you can spend less time developing custom cyber content and more time focusing on more critical tasks.

To learn how Graylog can help you cost-effectively optimize your telemetry, contact us today or watch a demo.

OpenTelemetry is emerging as the common framework for collecting observability data, and for good reason. It’s vendor-neutral, open source, and designed to collect traces, metrics, and logs in a consistent way. But while most of the buzz is around tracing and metrics, let’s not forget: logs are still the backbone of investigation and response.

That’s why Graylog now supports native collection of OpenTelemetry data over gRPC. If you’re already using OpenTelemetry in your stack—or you’re just curious how to consolidate structured telemetry logs with the rest of your event data—this new input makes things easier.

Let’s walk through what this feature does, why it matters, and how to get it working in your environment.

Why OpenTelemetry and Graylog Makes Sense

OpenTelemetry isn’t a single protocol—it’s a toolkit. The OpenTelemetry Protocol (OTLP) supports multiple transport formats, but gRPC is the go-to for real-time, high-throughput use cases.

By adding a gRPC input for OTLP logs, Graylog becomes a central observability engine, capable of handling not just syslog and Beats traffic, but also telemetry streams from cloud-native apps, Kubernetes clusters, and distributed services.

This unlocks:

• Structured, correlated log data enriched with trace context
• Faster detection and root cause analysis using familiar Graylog tools
• One less hop between your services and your SIEM or logging platform

What the gRPC Input Actually Does

The new input type allows Graylog to ingest OTLP-formatted logs over gRPC, a lightweight and efficient transport layer ideal for distributed systems.

Specifically, the input:

• Listens for incoming telemetry using the OTLP log signal
• Accepts data in protobuf format over gRPC (not HTTP)
• Maps and parses log fields into Graylog’s First-Level Field Mapping
• Supports TLS encryption, authentication, and service-level tagging

At this time, the input is optimized for log data, but future iterations could support metrics or trace signals as well.

First Level Field Mapping

At this time, the input is optimized for log data, but future iterations could support metrics or trace signals as well.

Resource and Attributes Mapping

• Resource Attributes: Prefixed with otel_resource_attributes_ and converted to Graylog fields.

• Resource Schema URL: Mapped to otel_resource_schema_url.

• Log Attributes: Prefixed with otel_attributes_.

• Log Schema URL: Mapped to otel_schema_url.

• Instrumentation Scope:

• otel_scope_name
• otel_scope_version
• otel_scope_attributes_*

Who Supports OTLP/gRPC?

If you’re working in the cloud (and let’s be honest, who isn’t?), it’s helpful to know which providers offer support for OpenTelemetry—especially if you’re planning to send logs over gRPC. The good news: all major clouds support OpenTelemetry in some form, and most offer native or collector-based support for OTLP over gRPC.

Here’s a quick common list of cloud support:

How To Set It Up in Graylog

Getting started is pretty straightforward.

1. Go to System > Inputs, and choose OpenTelemetry (gRPC).
2. Configure the Title, IP Bind Address, port (default is 4317), TLS certs (if needed), and optional service name.
3. Start the input.

On the collector side, configure your OpenTelemetry Collector to send logs via gRPC. Make sure your pipeline includes a logs exporter using the OTLP target, and you’re good to go. You can find full setup instructions in the Graylog documentation.

What You Can Do Once It’s Flowing

Once OpenTelemetry logs are hitting your Graylog instance, you can:

• Create dashboards that combine infrastructure and app-level data
• Use streams to isolate logs by service or environment
• Enrich logs with Graylog Information Model Schema
• Automate responses using alerts and pipelines

You can even correlate log events with traces—bringing observability and threat detection closer together. (Because let’s be honest: context is everything when you’re chasing down an incident.)

Common Pitfalls to Watch For

Getting gRPC right takes a little finesse. Here are a few gotchas:

• Port issues: gRPC often uses 4317, but firewall rules or existing services can interfere.
• TLS misconfigs: Certificates must match your endpoint and client trust setup.
• Collector mismatches: The OpenTelemetry Collector config must match Graylog’s gRPC endpoint and expected signal type.

If you’re stuck, the input diagnostics tool in Graylog’s web UI can usually point you in the right direction.

From Buzzword to Better Logs

OpenTelemetry is no longer just a forward-looking framework, it’s fast becoming table stakes. And now, with native gRPC support in Graylog, it’s easier than ever to collect telemetry logs without duct-taping another tool into your stack.

If you’re ready to see how structured telemetry logs can strengthen your visibility, give the new OpenTelemetry (gRPC) input a try. It just might become your new favorite way to get logs into Graylog.

Gamers of a certain age likely remember the video game Asteroids. You played as a little triangular spacecraft shooting at big space rocks that started traveling towards you slowly at first, then gained speed. As you revolved around trying to protect yourself by shooting them, you inevitably had to make some rapid decisions about which asteroids would harm your ship the most and which ones you could potentially ignore.

In cybersecurity, you do the same thing when trying to triage alerts. Just like not all asteroids would cause the same amount of damage to your ship, not all incidents have the same impact on systems and data. Triage in cybersecurity is a process that you can use to understand and prioritize threats, so you can more efficiently respond to alerts. When you have a structured approach to triaging incidents, you can appropriately allocate resources during the response process and communicate more effectively with everyone involved.

By centralizing all security activities and leveraging the right technologies, security teams can implement a structured, risk-based approach to triage in incident response that helps them protect systems more effectively.

What is Triage in Cybersecurity?

In cybersecurity, triage is a structured incident prioritization process that accounts for impact and urgency. The process begins with an initial assessment, focusing on severity, potential impact, and escalation likelihood. By implementing a triage process, security teams can investigate and respond to incidents faster, reducing the damage that a security incident can cause.

At a very high level, the triage process looks like this:

• Identify and analyze: quickly review the incident report to evaluate validity
• Incorporate threat intelligence: correlate incident with existing threat intelligence
• Apply predefined criteria: use set standards to determine the incidents that require immediate action

When prioritizing incidents, most organizations use the following three levels:

• High: Respond immediately
• Medium: Handle as soon as possible and review within 24 hours
• Low: Continue monitoring but no urgent action required

How triaging works in the incident response process

Triaging allows you to focus on the threats that can pose the most harm to your organization. As attackers continue to bombard companies with various attack types and methodologies, triaging gives you a way to organize your activities and optimize your response capabilities.

Detect and Report Initial Incident

Effective detections should allow you to identify, analyze, and report on security events by monitoring for abnormal activities across the environment. The initial report should include an overview of what happened and the assets impacted.

Assess and Categorize

In the assessment stage, incidents are evaluated based on impact, urgency, and severity. Once alerted to a potential even, your teams should have a way to assess the potential incident’s:

• Functional Impact: the systems involved and the incident’s effect on business operations
• Information Impact: the effect on data’s confidentiality, integrity, and availability, including potential theft of sensitive information
• Recoverability: incident size and resources impacted to determine the time and resources needed to recover

For example, the categorization of functional impact might look like this:

• None: services remain available to all users
• Low: critical services remain available but may not be delivered efficiently
• Medium: critical services unavailable to a portion of users
• High: critical services unavailable to all users

Prioritize Incidents

The assessment and categorization step allows you to determine an incident’s urgency. Using potential impact and severity as the basic building blocks of your prioritization, you should focus activities on high-priority incidents so you can minimize harm. In theory, prioritization should help your team avoid alert fatigue by allowing you to focus on the most immediate and dangerous incidents.

Assign and Allocate Resources

Each incident’s nature and severity guides resource allocation so that you can have the people with the right skills and experience working on the issue. This structured approach to resource allocation means that you can focus staff and response activities around addressing specific threats or critical systems, minimizing overall incident impact by responding faster.

Start Investigation

During the investigation, you start trying to find the incident’s root cause by gathering data and looking for indicators of compromise (IoCs). As part of this process, you will look for forensic evident that can include data like:

• IP addresses
• User access
• Asset hostnames
• Network traffic

Communicate and Coordinate

To resolve an incident as quickly as possible, you often need to coordinate across different team members and provide updates to impacted users. For example, security teams and network administrators may need to work together to contain a threat by preventing access to or from a specific network segment. With a centralized location for all activities, you can effectively and efficiently inform everyone involved in the incident response process and complete it faster.

What are the challenges of incident response alert triage?

Despite the important role that alert triage plays in mitigating an incident’s impact, many security teams struggle to implement an effective strategy. Some of the main challenges they face include:

• False positives: Alerts lack important context and fail to identify a real security incident.
• Alert fatigue: Chasing down too many false positives causes security teams to tune out alerts or fail to respond to actual incidents.
• Human error risk: Analysts manually prioritizing alerts can make mistakes due to environment and incident complexity.
• Immature data analytics: Machine learning (ML) and artificial intelligence (AI) models that focus on IoCs can inaccurately prioritize alerts, especially if they are not focused on cybersecurity use cases.

What are the benefits of alert triage?

A security operations center (SOC) gain various benefits when it appropriately triages alerts, including:

• Improved Efficiency: Quickly identifying high-priority incidents among numerous security alerts reduces response times and helps focus on real threats.
• Reduced Alert Fatigue: A structured approach makes it easier to filter out false positives so analysts can concentrate on legitimate, high-priority alerts.
• Enhanced Decision-Making: Using indicators of compromise and other threat intelligence gives SOCs context about the alert and an incident’s potential impact for faster assessment and response.
• Proactive Security Posture: Identifying suspicious activity promptly enables security teams to counteract malicious activity before it escalates.

Best Practices for Improving Triage for Incident Response

Alert triage helps your team protect critical assets and respond to potentially harmful incidents faster.

Centralize Security Activities

During an incident, coordinating and communicating across various people and departments is key to a fast, efficient response. When you create a central hub for all security activities,  you can assign people the permissions they need to monitor or interact with the investigation. Additionally, with everyone working from the same information, you can document the triage process and incident response activities for compliance purposes.

Use Security-Focused AI/ML

AI/ML can improve your team’s incident response processes, but you should look for analytics models that are purposely trained on cybersecurity use cases. When looking for an anomaly detection solution, you should consider whether it:

• Defined normal activity
• Identified outliers using behavioral analysis
• Sends alerts from the activity deviates from the normal levels
• Provides an anomaly index to generate alerts based on your team’s configurations

Leverage Risk Scores

With risk scoring, you can create a quantitative metric for prioritizing an incident. However, you should consider two different types of risk scores:

• Event: the potential impact to your environment to help decide whether an investigation is necessary
• Asset: the potential impact to a critical assets based on both the event’s risk and any vulnerabilities associated with the assets that make it easier for attackers to complete their objectives

Map Detections to Attack Methods

Your detections, like Sigma rules, help you identify security incidents. When you map detections to threat actor tactics and techniques, you can more accurately understand the potential impact. For example, mapping Sigma rules to the MITRE ATT&CK framework can help you identify high-impact issues based on your current threat coverage without requiring your team to have specialized security skills.

Incorporate Generative AI Purposefully

Generative AI (GenAI) provides a different value than anomaly detection analytics. GenAI models are well-suited to ingesting large amounts of raw data then providing summaries of it. For security teams, this offers a benefit when trying to sort through the log data generated by their environment. When SOCs have a security-focused GenAI tool, they can use the log and event data to generate detailed reports that include key finding and recommended remediation actions.

Graylog Security: Risk Scoring and High-Fidelity Alerts to Improve Incident Response

Using Graylog Security, you can rapidly mature your alert triage capabilities. Graylog Security’s Illuminate bundles include rulesets with content that includes Sigma detections, enabling you to uplevel your monitoring by incorporating threat hunting capabilities and correlations to ATT&CK TTPs.

By leveraging our cloud-native capabilities and out-of-the-box content, you gain immediate value from your logs. Our anomaly detection ML improves over time without manual tuning, adapting rapidly to new data sets, organizational priorities, and custom use cases so that you can automate key user and entity access monitoring.

With our intuitive user interface, you can rapidly investigate alerts. Our lightning-fast search capabilities enable you to search terabytes of data in milliseconds, reducing dwell times and shrinking investigations by hours, days, and weeks.

To learn how Graylog Security can help you implement robust threat detection and response, contact us today.

We’re all exhausted—both by the problem and by hearing about it. False positives and overwhelming alert volume have long plagued security operations. And despite years of innovation, solutions have remained elusive.

Alert volume. Alert fatigue. SOC burnout.

This persistent problem puts security teams in a tough position:

• Enable a broad set of detections to catch possible threats—knowing it will lead to high alert volume, false positives, and potential SOC burnout.
• Or, tune alerts tightly or disable noisy ones—risking blind spots and missing critical early indicators of an attack.

For CISOs and SOC managers, it’s a lose-lose scenario. And worse, the challenge is always shifting as the attack surface expands, adversaries evolve, and detection techniques multiply.

Adding more security tools and analytics often makes it worse, layering on even more data for analysts to triage.

The Real Answer: Evidence, Not Just Alerts

The solution isn’t finding the mythical “perfect alert” that only fires on true positives. It’s about automating the discovery of corroborating evidence that proves (or disproves) whether an alert points to a real threat.

If multiple pieces of evidence support the alert—its legitimacy is strengthened.

If no supporting data is found—it’s likely a false positive.

This is where Graylog 6.2 comes in.

Introducing A Smarter Way to Assess Risk

With version 6.2, Graylog enhances its Asset Risk Model, bringing greater precision to how risk of compromise is calculated—so you can focus on what matters most.

Recap: What Is Graylog’s Asset Risk Model?

Graylog Assets are an identity-construct for users and systems, recognizing that different log sources may reference the same “user” or “system” differently. The Asset Risk model was introduced last November, shifting triage from alert-based to asset-based. Instead of evaluating every alert in isolation, you focus on high-risk assets—users or machines—based on their composite risk score.

Each alert contributes to that score by factoring in:

• Severity of the detection method (e.g., correlation, outliers, ML anomalies)
• Environmental context
• Frequency and diversity of alerts

What’s New in 6.2?

Graylog 6.2 adds Adversary-Informed Defense to the model—introducing threat campaign awareness:

• Alerts are enriched with knowledge of adversary campaigns.
• Alerts linked to known threat campaigns are assigned higher risk.
• As more alerts from the same campaign surface—risk increases exponentially.

This creates an orthogonal signal, linking related evidence across both assets and threat campaigns, delivering a higher fidelity risk score.

Why This Matters

Collapsing individual alerts into asset-centric risk scores delivers immediate operational benefits:

✅ Less Time on False Positives

When a single alert fires but no corroborating activity is found, the asset risk remains low—reducing time spent chasing noise.

✅ No More “Sophie’s Choice”

The burden of tuning every rule to perfection is reduced. Graylog automatically groups related findings—even across assets—making alert triage more manageable and reducing the risk of blind spots.

✅ Faster Investigations

The initial triage questions—“who, what, where”—are answered automatically by the asset context and associated evidence, letting analysts jump straight into deeper investigation.

The New SOC Efficiency Model

The triad of:

• Asset Risk
• Exposure Awareness
• Adversary-Informed Defense

delivers the precision, automation, and prioritization that modern security operations demand.

When paired with Graylog’s embedded investigation guidance and automation, the result is a leap forward—whether you’re just starting your security journey or running a mature SOC.