Your Domain Name System (DNS) infrastructure enables users to connect to web-based resources by translating everyday language into IP addresses. Imagine going into a restaurant, in the age before the internet, only to find that the staff speaks and the menu is written in a different language from yours. Without some shared communication form, you can’t order dinner, and they can’t give you what you want. Finally, someone comes into the restaurant who speaks both languages, acting as the translator so you can get the service you need.

A DNS infrastructure is the translator for cloud-based operations for continued services. However, when malicious actors target your DNS, a successful attack can lead to downtime or a data breach.

To mitigate risk, you should implement some DNS security best practices, including knowing what logs help you monitor for and detect a potential incident.

What is DNS security?

DNS security refers to the measures taken to protect the Domain Name System (DNS) infrastructure from cyber attacks. DNS translates a human-readable URL (Uniform Resource Locator) into a machine-readable IP address, routing user requests to the appropriate digital resources.

Cyber attacks against the DNS infrastructure can lead to:

• Website defacement
• Traffic hijacking sending users to malicious websites or intercepting communications
• Unauthorized access to sensitive information
• Distributed Denial of Service (DDoS) attacks causing service outages and business interruption

DNS security controls typically include:

• Redundancy: Using multiple DNS servers spread across different locations to prevent a single point of failure
• DNS Security Extensions (DNSSEC): Protocols providing authentication and data integrity
• DNS logging: Monitoring for and detecting malicious activities

Why is DNS security important?

The history of DNS gives insight into why it is not a secure technology. Originally created in 1983 so people could more easily navigate the nascent internet, no one predicted this new connectivity would change and become critical to daily operations.

Your DNS infrastructure acts as the foundation for your digital business operations meaning the service disruptions lead to downtime and lost revenue.

A successful attack against your DNS infrastructure can lead to:

• Business disruption: Without the ability to translate URLs into IP addresses, users and customers cannot connect to digital services.
• Lost revenue: Without the ability to connect to services, customers cannot engage in transactions, like being able to purchase items in an e-commerce store.
• Data breach: Compromising DNS services can lead to unauthorized data transfers, modification, or access that impact sensitive data’s integrity and privacy.
• Compliance risk: DNS is included in various compliance frameworks and mandates, including the Payment Card Industry Data Security Standard (PCI DSS) and International Organization for Standardization (ISO) 27002-2022

6 DNS Attack Types and How to Prevent Them

As attackers increasingly target the DNS infrastructure, knowing these four common attack types can help you implement security controls and the appropriate monitoring to mitigate risk.

DoS and DDoS

Many attacks against the DNS infrastructure fall into these categories, even if they use different methodologies for achieving the objective. Although similar, you should understand the following differences:

• Denial of Service (DoS): one computer using one internet connection sends high volumes of traffic to a remote server
• Distributed Denial of Service (DDoS): multiple devices across multiple internet connections target a resource, often using a botnet consisting of devices infected with malware

These attacks flood a DNS server with requests and traffic. As the server attempts to manage the responses, it becomes overloaded and shuts down.

DNS amplification attacks

One DDoS attack type is DNS amplification, in which malicious actors send high volumes of DNS name lookup requests to publicly accessible, open DNS servers. Instead of using their own IP in the source address, the attackers spoof the target’s address so that the DNS server responds to the target.

DNS hijacking

In a DNS hijacking attack, malicious actors make unauthorized changes to the DNS settings which redirect users to deceptive or malicious websites. Some varieties of DNS hijacking attack include:

• Cache poisoning: inserting false data into the DNS server’s cache to redirect users when they try to access the website
• Server hijacking: gaining unauthorized access to a domain’s DNS records and changing A or AAAA records that redirect users to a malicious IP address or attacker-controlled server

DNS Spoofing

DNS spoofing, also called DNS poisoning, exploits security gaps in the DNS protocol. The attacker gets in between the browser and the DNS server to supply the wrong response, diverting traffic to the malicious website.

DNS tunneling

DNS tunneling is a sophisticated attack where malicious actors insert data into the communication path between the browser and server. This enables them to bypass several defensive technologies, including:

• Filters
• Firewalls
• Packet capture

This process routes queries to a command and control (C2) server, enabling them to steal information.

DNS Logging Best Practices for Improved Security

Whether you build your own DNS infrastructure or use a managed service, you should be integrating your DNS logs into your overarching security monitoring. While the logs should provide similar information, the field used changes based on your DNS server’s manufacturer. However, you should look for log fields supporting the following categories and event types.

Zone operations

In DNS-speak, the zone refers to the domain. Some data you should consider collecting include log fields related to the creation, deletion, or modification to:

• Zones
• Records
• Nodes

DNS Security Extensions (DNSSEC)

DNSSEC are configurations that use digital signatures to authenticate DNS queries and responses. Some data you should consider collecting include log fields related to:

• Addition of new keys or trust points
• Removal of keys or trust points
• Exports of metadata

Policies

DNS policies allow you to

• Balance traffic loads
• Assign DNS clients based on geographic location
• Create zones
• Manage query filters
• Redirect malicious DNS requests to a non-existent IP address

Some data you should consider collecting include log fields related to the creation, deletion, or modification of:

• Client subnet records
• Server level policies
• Forwarding policies
• Zone policies

Graylog Security: Correlating DNS Log Events

DNS logs are often difficult to parse, sometimes creating a blind spot when monitoring DNS security. Graylog Security offers out-of-the-box content that streamlines this process with pre-built content to rapidly set up and start monitoring your DNS security.

Our 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 threat detection and incident response (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 financial services industry has been a threat actor target since before digital transformation was even a term. Further, the financial services organizations find themselves continuously under scrutiny. As members of a highly regulated industry, these companies need to comply with various laws to ensure that they effectively protect sensitive data.

The adoption of the Digital Operational Resilience Act (DORA) places additional resilience compliance requirements on the European financial sector, ones that centralized log management can help them manage.

What is the Digital Operational Resilience Act (DORA)?

Formally adopted by the European Parliament and goes into effect on January 17, 2025, the Digital Operational Resilience Act (DORA) established uniform network and information system security requirements across the financial sector and the third-parties that provide Information Communication Technology (ICT) services, including cloud platforms and data analytics services.

The DORA regulatory framework requires organizations to make sure they can withstand, respond to, and recover from ICT-related disruptions and threats. It sets out standardized requirements for  preventing and mitigating cyber threats across all European Union (EU) member states.

Who will DORA apply to?

To achieve DORA’s resilience goals, the regulation applies to a long list of entities within the financial services industry and third-parties that enable them, including:

• Credit institutions
• Payment institutions
• Account information service providers
• Electronic money institutions
• Investment firms
• Crypto-asset services providers
• Central security depositories
• Central counterparties
• Trading venues and repositories
• Managers of alternate investment funds
• Management companies
• Data reporting service providers
• Insurance and reinsurance undertakings
• Insurance, reinsurance, and ancillary insurance intermediaries
• Institutions for occupational retirement provision
• Credit rating agencies
• Administrators of critical benchmarks
• Crowdfunding service providers
• Securitisation repositories
• ICT third-party service providers

What are DORA’s key provisions?

Section II outlines DORA’s key requirements including:

• Article 6 ICT risk management framework: strategies, policies, procedures, ICT protocols and tools necessary to protect information and ICT assets
• Article 7 ICT systems, protocols and tools: use and maintain updated ICT systems, protocols and tools that are appropriate to operational magnitude, reliable, equipped with sufficient capacity, and technologically resilient
• Article 8 Identification: identify, classify, document, and engage in a risk analysis for all information and ICT assets and processes, including those on remote sites, network resources, and hardware equipment
• Article 9 Protection and prevention: develop, document, implement, and maintain security policies and technical controls that protect data confidentiality, integrity, availability, and authenticity and continuously monitor the effectiveness of controls
• Article 10 Detection: implement mechanisms and provide sufficient resources to monitor and detect, across multiple layers of control, anomalous activity by using defined thresholds and criteria that trigger and initiate incident response processes
• Article 11 Response and recovery: establish and implement an ICT business continuity policy based on a business impact analysis (BIA) that includes dedicated, appropriate, documented, and tested arrangements, plans, procedures, and mechanisms for ensuring critical functions, responding to and resolving incidents, enable incident containment, estimate preliminary impact, damage, and losses, and establish communications and crisis management activities
• Article 12 Backup policies and procedures, restoration and recovery procedures and methods: develop, document, implement and test backup, restoration, and recovery policies, procedures, methods, and service level agreements that can be activated without jeopardizing network ir information system security or data availability, authenticity, integrity, or confidentiality
• Article 13 Learning and evolving: implement capabilities and staff to gather vulnerability and cyber threat information, develop ICT-security awareness programs, and review incident detection, response, forensic analysis, escalation, and internal and external communication capabilities to improve business continuity
• Article 14 Communication: implement crisis communications plans and policies that inform internal staff and external stakeholders about ICT-related incidents or vulnerabilities

For small and non-interconnected investment firms, payment institutions, electronic money institutions, and occupational retirement provisions, or other exempt entities, Article 16 articulates a simplified ICT risk management framework that requires:

• Implementing and maintaining an ICT risk management framework with mechanisms and measures that mitigate risk
• Continuously monitoring ICT system security and functioning
• Protecting data availability, authenticity, integrity, and confidentiality using sound, resilient, and updated ICT systems, protocols, and tools
• Promptly identifying and detecting ICT-related risks, incidents, and anomalous activities
• Identifying key ICT third-party service provider dependencies
• Implementing business continuity plans, response, and recovery measures, including backup and restoration
• Testing risk mitigation measures, data protections, and business continuity plans
• Implementing changes based on tests and post-incident analyses, including changes to ICT risk profile, ICT security awareness programs, and staff and management digital operational resilience training

The Regulatory Technical Standards

On January 17, 2024, the final draft of the Regulatory Technical Standards was published. Under Section V ICT Operations Security, Article 12 Logging defines acceptable procedures, protocols, and tools.

The logging procedures and protocols should:

• Identify the events to log
• Retain logs for an appropriate time
• Enable the secure handling of log data

When using logs to detect anomalous activities, organizations are required to collect log events related to the following:

• Identity and access, including logical and physical access control
• Capacity management
• Change management
• ICT operations, including system activities
• Network traffic, including performance

The details captured in the logs should align with their purpose and usage to enable accurate alerting and forensic analysis. Under Chapter III, Article 23 organizations shall implement detection mechanisms allowing them to:

• Collect, monitor, and analyze internal and external factors, including logs collected according to Article 12
• Generate alerts for identifying anomalous activities and behaviors with automated alerts based on predefined rules
• Prioritize alerts to manage incidents within the required timeframe
• Record, analyze, and evaluate relevant information on all abnormal activities and behaviors either automatically or manually

When establishing criteria that triggers threat detection and incident response (TDIR), organizations shall consider the following criteria:

• Indications that malicious actors carried out malicious activity or compromised a system or network
• Data losses detected that impact data availability, authenticity, integrity, and confidentiality
• Adverse impact on transactions and operations detected
• System and network unavailability

Compliance Monitoring For DORA Compliance

Centralized log management with security analytics enables you to continuously monitor your environment and create high-fidelity alerts that enable faster response, investigation, and recovery. To help you meet DORA compliance requirements, you can use your centralized log management solution to support:

• Access monitoring
• Network monitoring
• Endpoint security
• Patch management
• Data exfiltration/data loss
• Incident and response

Further, it enables many of DORA’s key requirements, including:

• Threat hunting
• Detection with high-fidelity alerts
• Remediation of vulnerabilities
• Incident investigation

Access Monitoring

Your centralized log management solution ingests access logs from across your environment, including on-premises and cloud-based resources. When paired with user and entity behavior analytics (UEBA), it gives you a robust access monitoring solution to detect and investigate anomalous behavior, even within a complex environment.

By using a centralized log management solution with security analytics, you can engage in security functions like:

• Privileged access management (PAM)
• Password policy compliance
• Abnormal privilege escalation
• Time spent accessing a resource
• Brute force attack detection‍

Network Monitoring

When monitoring network security, you’re usually correlating and analyzing data from several different tools.

Your firewalls define the inbound and outbound traffic, giving you the ability to detect suspicious activity like data traveling to a cybercriminal-controlled server.

Intrusion detection systems and intrusion prevention systems (IPS) provide visibility into potential evasion techniques. When combined with your firewall data, you have a more complete story. 

When the centralized log management solution also incorporates security analytics, you can set baselines for normal network traffic that help you detect anomalies for visibility into a potential security incident.

Data exfiltration

Between credential-based attacks, malware/ransomware attacks, and Advanced Persistent Threats (APTs), monitoring your systems for data exfiltration is critical to DORA compliance. 

If your centralized log management solution provides security analytics that you can combine with threat intelligence, your dashboards and high-fidelity alerts enable you to more rapidly detect, investigate, and respond to security incidents. 

For example, when you can aggregate your network monitoring and antivirus logs then correlate them with UEBA to detect anomalies, you can create alerts that provide insights into abnormal data downloads indicating a security incident. 

Incident response and automated threat hunting

With lightning fast search and proactive threat hunting capabilities, you can implement a robust incident response plan that enables digital resilience. 

For example, if you can create queries using parameters instead of specific values, you can optimize search for real-time answers. 

To take a proactive approach, you can create parameterized searches that look for advanced threat activities like:

• Abnormal user access to sensitive information
• Abnormal time of day and location of access
• High volumes of files accessed
• Higher than normal CPU, memory, or disk utilization
• Higher than normal network traffic

Compliance reporting and post-incident learning

Your senior leadership team needs to know what happened and how quickly you responded, but it may not need the deep technical details. Your centralized log management solutions dashboards can provide the high level visualizations that enable everyone to evaluate the security incident after you restore and recover your systems.

For example, you could use a dashboard to show:

• Start of incident: when logs documented changes
• Incident activities: what types of changes the logs documented to highlight what the threat actor tried to do
• Containment/Eradication: when logs stop reporting the activities indicating the threat actor is no longer acting in the system

Graylog Security: Security analytics without complexity

With Graylog’s security analytics and anomaly detection capabilities, you get the cybersecurity platform you need without the complexity that makes your team’s job harder. With our powerful, lightning-fast features and intuitive user interface, you can lower your labor costs while reducing alert fatigue and getting the answers you need – quickly.

Our prebuilt search templates, dashboards, correlated alerts, and dynamic look-up tables enable you to get immediate value from your logs while empowering your security team.

Many organizations today have strict data privacy regulations that they must comply with. These privacy regulations can often clash with the requirements of security, application and operations teams who need detailed log information. This how to guide walks you through redacting message fields for privacy purposes.

At Graylog, many of the organizations who use our tool are logging sensitive data that may contain personally identifiable information, health related data or financial data. Often, to ensure compliance with data privacy laws, this information must be redacted or hidden from many of the end users of the tool.

I’m going to walk through a simple way we can use processing pipelines to scrub personally identifiable information from a log message so that it is only visible to an elevated Graylog user account.

Caution: To achieve this functionality we need to replicate the message. This will increase the amount of data written to OpenSearch which may impact licensing or storage requirements.

Configuration

In my lab environment I have Auditbeat running on my host machine.. Log messages are sent to a Graylog Illuminate stream called “Illuminate:Linux Auditbeat Messages”.

In these messages I can see my username. First in the user_name field and again in the message field.

Pipeline Rule

For privacy purposes I am going to redact these usernames and route the messages into a separate stream, “Auditbeat Redacted”. I’ll retain the unredacted message in the “Illuminate:Linux Auditbeat Messages” stream. We’ll then restrict the access rights to these different streams.

To achieve this we need to write a pipeline rule that will create a copy of the message, edit the contents, route it into the new stream and remove the copy from the original stream.

This is what the complete pipeline rule looks like, I’ll walk through it line by line:

Identify The Message

The first step in the rule is to identify the messages we want to modify. This is achieved by finding messages with the relevant username field and also performing a check to ensure the message hasn’t already been modified. This check is important and I’ll explain why in the next part:

Clone The Message

After we have identified the message we want to process we then clone the message. 

IMPORTANT: When a message is cloned an exact copy of the message is created however it will be given a new message ID. From the view of the processing pipeline, this message has not been processed so it will flow through the pipeline as a newly seen message. If the check in the previous block was not performed, we would end up in an infinite loop of cloning the same message:

As the message field in the log contains the username, we are going to first redact it from here, before removing it from the auditbeat_user_name field itself. I am using the original $message field to find the username, but then replacing the the message field in the cloned message, cloned_mess:

We then replace the username field with “REDACTED”:

Stream Routing

Before routing and removing from the relevant streams:

Once we have written the rule, we need to apply it to our Auditbeat stream. Create a new pipeline, ensure you have selected the relevant stream in the Pipeline Connections, and apply the rule at an appropriate stage. In my case I only have 1 rule so I am applying it at Stage 0:

Search And Share

If we now go to the Search page, we should be able to see the redacted and non-redacted fields when switching between the Auditbeat stream and the Auditbeat Redacted stream:

We can now share these streams out with the relevant user accounts. In my example I have created a test account of an analyst who is only allowed to view the REDACTED stream. On the Streams page I can click on Share and assign this user Viewer rights to this stream:

If we log in under this user, you can see that they only have access to the Auditbeat Redacted stream:

Additional Thoughts

Finally, with Graylog Operations and Graylog Security, you will be able to audit which users are accessing sensitive data inside of Graylog for even more control and oversight.

As you can see, processing pipelines are a very powerful way to modify, enrich and filter your log messages. If there are particularly novel or complex pipelines that you think would be useful to the rest of the community, please share them on the Graylog Marketplace.

A recent analysis by JPMorganChase criticized the CVSS scoring process, finding missing context leads to misleading prioritization. When it comes to cybersecurity, patching vulnerabilities often feels like the Holy Grail. Get those CVEs patched, and you’re safe, right? Well, not exactly. As we know, patching isn’t as straightforward—or as effective—as we’d like to believe. Between limited resources, business interruptions, and the sheer volume of vulnerabilities, aiming for 100% patching of even critical and high severity findings can feel like chasing the wind. 

Patching, while important, isn’t the ultimate answer to securing your environment.

The Obstacles to Patching Vulnerabilities

1. Volume of Vulnerabilities

The number of disclosed vulnerabilities continues to skyrocket each year. The National Vulnerability Database (NVD) catalogs tens of thousands of new vulnerabilities annually. How do you decide what to patch when every scanner generates a flood of critical alerts?

2. Business Continuity Concerns

Applying patches often means downtime, testing, and the risk of breaking critical systems. For organizations with legacy infrastructure, patching a production server could have unintended ripple effects that outweigh the vulnerability itself.

3. Resource Constraints

Whether it’s budget, people, or tools, cybersecurity teams are stretched thin. A limited team can’t patch everything without neglecting other critical duties like incident response, user awareness training, or threat hunting.

4. Exploit Context

Not every vulnerability is weaponized or even exploitable in your specific environment. Yet, traditional vulnerability management often treats all vulnerabilities as equally urgent, leading to patching fatigue.

Why 100% Patching Shouldn’t Be the Goal

Here’s the reality: patching every vulnerability isn’t just impractical; it’s unnecessary. Security isn’t about perfection; it’s about prioritization. You’re better off focusing on vulnerabilities that truly matter to your organization’s risk posture.

Why shouldn’t you aim for 100%?

• Not All Vulnerabilities Pose a Real Risk

A vulnerability in an unexposed system or one without a known exploit may not require immediate action. Over-focusing on low-risk vulnerabilities can leave high-impact risks unattended.

• Attackers Focus on Exploitable Opportunities

Attackers don’t care about your patch percentage—they care about the paths that lead to valuable assets. Patching systems indiscriminately can distract from understanding those paths.

• Runtime Context Matters More

Static vulnerability assessments tell you what could go wrong, but runtime context reveals what is happening. This is the key to distinguishing between theoretical risks and active threats.

How Graylog Helps: Asset-Based Risk with Runtime Context

At Graylog, we recognize the goal isn’t 100% patching—it’s 100% understanding. That’s where our asset-based risk approach comes into play. Graylog assesses a risk score based on real-world activity along with your vulnerability data to help you focus on what truly matters.

1. Runtime Activity as Necessary Context

Traditional vulnerability management is like looking at a static map—you see the terrain but not the movement. Graylog goes further by incorporating runtime activity. We help you answer questions like:

• Is the vulnerable asset being actively targeted?
• Is it communicating with known malicious IPs?
• Are unusual processes or behaviors happening on the system?

This real-time insight helps you prioritize vulnerabilities that attackers are actually exploiting.

2. What’s Happening vs. What Could Happen

Patching vulnerabilities addresses what could happen, but Graylog helps you recognize what is happening. By correlating log data, threat intelligence, and asset behavior, we surface indicators of compromise (IOCs) and tactics, techniques, and procedures (TTPs) that reveal active threats.

3. True Compromise Detection

Graylog’s focus isn’t just on potential risks but actual compromises. Our platform helps you identify and respond to incidents that have crossed the line from theoretical to real-world attacks. This allows you to spend less time chasing low-priority patches and more time addressing active threats.

Conclusion: Focus on What Matters

In cybersecurity, perfect can’t be the enemy of good. Chasing 100% patching is like locking every window in the house while the burglar walks in through the front door. Instead, focus on understanding your environment, prioritizing high-impact vulnerabilities, and recognizing true compromises.

With Graylog’s asset-based risk approach, you get the necessary context to separate the noise from the signal. By focusing on what’s happening, not just what could happen, you can align your resources to defend your organization effectively.

Everyone remembers that one required writing class they needed to take. If you’re like a lot of other security analysts, you assumed that your job would focus on using technology, not writing research papers. However, in today’s business environment, cyber incidents are critical business events, especially as governments and agencies create more reporting requirements. 

A cyber incident report is a key element for your incident response process, especially when your organization reviews activities to identify areas of improvement during the lesson’s learned phase. When implementing a structured incident response plan, you should know what an IT security incident response report is, why you need one, and what it should contain.

What Is Cyber Incident Reporting?

Cyber incident reporting involves documenting the details of incidents like:

• Cyber attacks
• Data breaches
• Unauthorized access

The IT security report typically details an incident’s timeline, including:

• Date of incident
• Attacker activities and timing
• Accounts, resources, and/or data affected
• Remediation steps taken

Cyber reporting is a critical part of the incident response process because organizations can use the documents as part of:

• Lessons learned: Assessing incident detection and response to identify areas of improvement
• Implementing controls: Developing new controls to prevent a similar incident from occurring in the future
• Notification requirements: Communicating with affected parties or others as required by law

Why Are IT Security Reports Important?

Documenting an incident’s details and notifying relevant stakeholders promptly provides various benefits.

Maintain Compliance

Most legal and regulatory frameworks require organizations to report cybersecurity incidents to various involved parties, including:

• Law enforcement
• Cybersecurity agencies
• Affected parties, like individuals or companies whose data was compromised

Laws have varying timelines for providing notification. For example, the General Data Protection Regulation (GDPR) mandates that organizations report a data breach within 72 hours. Meanwhile, under the Health Insurance Portability and Accountability Act (HIPAA), covered entities must notify affected parties within 60 days.

Failure to comply with these notification requirements can lead to fines or other penalties.

Improve Risk and Threat Awareness

A detailed cyber security incident report provides insight into potential weaknesses. By analyzing the incident’s underlying causes, security teams can improve their risk models and close security gaps. The organization can use this information to address new threats then implement new security controls to mitigate risk.

Build Trust With Clients, Customers, and Stakeholders

Transparency during data breaches builds trust with stakeholders by demonstrating professionalism and urgency. Open communication about incidents reinforces that no organization is immune to cyber threats, showcasing commitment to data protection. While the organization will remove sensitive information related to its own security, the IT security incident report provides a timeline that can act as the foundation for these communications.

Cyber Reporting Challenges

Reporting, like compliance, is a process that can become overwhelming, especially for understaffed security teams.

Gathering Information

Under the pressure of an ongoing incident, security teams need to investigate quickly. Isolation and recovery are the critical steps. They document their activities, but they have no time to organize their documentation. Once they contain the threat and recover systems, they spend time putting the puzzle pieces together.

Creating a timeline

In a perfect world, incident investigations start with the first alert that the attackers trigger. Across complex, interconnected systems, the activity that initiates an investigation may not be that first alert. Additionally, many alerts only provide a quick glimpse into a moment in time. For example, Sigma rules provide insight that an event occurred but often lack context, like previous or follow up events.

Turning data into a narrative

Alerts and ticketing system notes are simply data points. They provide insight into discrete actions. For a cybersecurity incident report, analysts need to turn these events into a narrative. For example, the system may have sent a Windows Event alert with the ID 4625, “attempt made to logon with unknown user name or bad password and failed.” However, the security analyst needs to translate that “what happened” into the “why it matters.”

Using sensitive environment data

Although large language models (LLMs) can turn raw data into a narrative, cyber incident report data contains sensitive information, including user IDs or internal identifiers. Unfortunately, feeding data into a public LLM makes that information part of the technology’s database, creating a data leak issue.

What Needs to Be in a Cyber Security Incident Report?

Since organizations use IT security reports to document and learn from incidents, reports need to include technical and non-technical information that outlines various event details.

Executive summary

The executive summary provides a clear, concise overview of the cybersecurity incident for a broad audience, highlighting:

• Key finding
• Actions taken
• Impact on stakeholder
• Incident ID
• Incident summary, with type, time, duration, and affected systems/data

Incident details

This section captures critical information about the incident, including:

• Nature of threat
• Business impact
• Immediate actions taken
• When/how incident occurred
• Who/what was affected
• Overall scope

Attack vector details

Attack vector details identify the specific vulnerabilities that attackers exploited, including technical details like:

• Open ports
• Weak credentials
• Phishing URLS
• Source IP addresses for Distributed Denial of Service (DDoS) attacks

Systems and assets affected

This section outlines the technology assets impact, including:

• Servers
• Storage
• Network device
• User devices

Additionally, it details the damage that the incident causes, like data corruption, to evaluate the impact on business operations.

Business impact assessment

A business impact assessment evaluates the operational disruptions and data compromises resulting from the cyber incident. It reviews any

• Financial losses
• Regulatory implications
• Long-term consequences

Incident response actions

Incident response actions highlight the steps taken from detection to remediation, including

• Preparation
• Containment
• Recovery

Detailing these activities can identify areas of improvement that enable the organization to update controls.

Communication and notification logs

Communication and notification logs show how the organization shared information about the incident for compliance and accountability purposes. These logs detail communications with all affected parties informed, including

• Internal teams
• External stakeholders
• Regulatory authorities

Conclusions

In the conclusions, the cybersecurity incident report provides a comprehensive overview of the event, its impact, and insights for future prevention.

Graylog Security: Responsible AI for Automating IT Security Incident Reporting

Reading every log generated during a security incident is overwhelming, but the individual logs are only limited pieces of discrete information. To gain full visibility into an incident, you need to aggregate the data and understand the timeline.

With Graylog Security, you can create AI-generated incident reports using your organization’s log data while maintaining control and security over the information in the logs. At the click of a button, our AI interface analyzes all the logs and provides a report based on what it found, what it sees happening based on the data, and recommendations for mitigating the issue. Since all data you need remains in your Graylog deployment or in Data Warehouse, you maintain control, security, and privacy over your most sensitive environment data.

“Aren’t you a little short for a Stormtrooper?” In this iconic Star Wars moment, Princess Leia lazily responds to Luke Skywalker, disguised as one of her Stormtrooper captors and using authentication information to open her cell.

In other words, Star Wars acts as an analogy for a cross-site request forgery (CSRF) attack. In a CSRF attack, malicious actors use social engineering so that end-users will give them a way to “hide” in their authenticated session. Disguised as the victim, the attackers can make changes and engage in transactions based on the account’s permissions.

With a cross-site request forgery cheat sheet, you can learn the basic principles underlying these attacks and some best mitigation practices.

What is Cross-Site Request Forgery (CSRF)?

A cross-site request forgery (CSRF) attack involves inheriting the victim’s identity and privileges so that the attacker can perform actions within the site. Typically, browser requests include credential information, like a user’s:

• Session cookie
• IP address
• Windows domain credentials

After a user authenticates into the site, the attackers target functions that allow them to make changes, like:

• Changing an email address
• Creating a new password
• Making a purchase
• Transferring funds
• Elevating privileges

The site treats these forged, authenticated requests as legitimate and authorized. The attacks focus on making changes within the site because any data requested would go to the victim.

CSRF attacks can also be called:

• XSRF
• Sear Surf attacks
• Session Riding
• Cross-Site Reference Forgery
• Hostile Linking

Three Types of CSRF Attacks

Malicious actors can deploy three types of CSRF attacks.

LOGIN CSRF Attack

In a login CSRF attack, malicious actors:

• Get the user to log into an account the threat actor controls
• Victim adds personal data to the account
• Attackers log into the account to collect data and victim activity history

Stored CSRF Flaws

Attackers can store an attack on a vulnerable site using fields that accept HTML using:

• IMG tag
• IFRAME tag

This increases the damage of the attack for two reasons:

• Victims may “trust” the compromised site.
• Victims may already be authenticated into the site.

Client-side CSRF

The client-side CSRF attack manipulates the client-side JavaScript program’s requests or parameters, sending a forged request that tricks the target site. These attacks rely on input validation issues so the server-side has no way to determine whether the request was intentional.

How does a CSRF attack work?

At a high level, attackers do two things:

• Create the malicious code
• Use social engineering to trick the victim

CSRF attacks rely on:

• Web browsers handling session-related information
• Attackers’ knowledge of web application URLs, requests, or functionality
• Application session management only using browser information
• HTML tags that provide immediate HTTP[S] resource access

By clicking on the malicious URL or script, the victim sets up the attacker’s ability to exploit:

• GET requests: Browser submits the unauthorized request.
• POST requests: Victim clicking on a link or submit button executes the action.
• HTTP methods: APIs using PUT or DELETE could have requests embedded into an exploit page, but same-origin policy restrictions in browsers can protect against these unless the website explicitly allows these requests.

How is Cross-Site Request Forgery Different from Cross-Site Scripting (XSS)?

These attacks exploit different aspects of web interactions:

• Cross-Site Request Forgery: leverages use identity to take state-changing actions without victim consent
• Cross-site scripting: inject malicious code into web pages to manipulate user input and access sensitive data

Best Practices for Mitigating CSRF Attack Risk

A successful CSRF attack exploits specific application vulnerabilities and a user’s privileges. Following some best practices, you can mitigate these risks.

Use Synchronizer Token Patterns

As the most effective mitigation, many frameworks include CSRF protection by default so you may not have to build one yourself. The server-side-generated CSRF tokens should be:

• Unique per user per session
• Secret
• Unpredictable

The server-side component verifies the token’s existence and validity, comparing it to the token in the user session and the site should reject the request without it.

The mitigation uses per-session tokens because they offer the end-user a better experience. A per-request token would be more secure by limiting the available time frame for using them. However, for every user interaction, the site would need to generate a new token.

Alternative: Signed Double-Submit Cookie Patterns

In cases where you can’t use the synchronizer token, you could substitute the easy-to-implement, stateless Double-Submit Cookie pattern. With the Signed Double-Submit Cookie, you have a secret key that only the server knows to mitigate injection risks that would compromise the victim’s session.

While the Naive Double-Submit Cookie methods may be easier to implement and scale, attackers can bypass the protection more easily through:

• Subdomain exploitation
• Man-in-the-middle (MitM) attacks

Disallow Simple Requests

Simple requests are cross-origin HTTP requests that can be sent directly from the browser to the target service without getting prior approval. If the site uses <form> tags that allow users to submit data, the application should include additional protections. Some examples of additional protections include:

• Ensuring servers or APIs do not accept text/plain content types
• Implementing custom request headers for AJAX/APIs to prevent usability issues that using a double-submit cookie would create

Implement Client-side CSRF Mitigations

Since client-side CSRF attacks bypass traditional mitigations, you should implement the following:

• Independent requests: Ensure attacker controllable inputs cannot generate asynchronous requests
• Input validation: Ensure that input formats and request parameter values only work for non-state-changing operations
• Predefined Request Data: Store safe request data in the JavaScript code

SameSite (Cookie Attribute)

The browser uses this attribute to determine whether to send cookies with cross-site requests and has three potential values:

• Strict: prevents the browser from sending the cookie to the target site in all cross-site browsing contexts that involve following a regular link
• Lax: maintains a logged-in session when the user follows an external link, but blocks high-risk request methods

Verify Origin with Standard Headers

This method examines the HTTP request header value for:

• Source origin: where it comes from
• Target origin: where it’s going to

When these match, the site accepts the request as legitimate. If they do not match, it discards the request.

Involve the User

Involving users means they have to take action that mitigates risks from unauthorized operations. Some examples include using:

• Re-authentication mechanisms
• One-time tokens

While CAPTCHA requires user interaction, it does not always differentiate user sessions. While it would make attacker success more difficult, it isn’t a suggested mitigation technique.

Graylog Security: Mitigating CSRF Risk with High Fidelity Alerts

Graylog Security provides prebuilt content that maps security events to MITRE ATT&CK so organizations can enhance their security posture. 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 threat detection and incident response (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.

Graylog Introduces Advanced Data Routing to Align Costs with Data Value

HOUSTON – October 21, 2024 — Graylog, a leader in Threat Detection, Investigation, and Response (TDIR), today unveiled significant security advancements to drive smarter, faster, and more cost-efficient security operations. The company’s latest capabilities include advanced data routing, asset-based risk scoring, and AI-generated investigation reports. 

These enhancements, and many others in the Fall 2024 release, help organizations realign their time and financial investment with security objectives, empowering security teams to confidently reduce risk. With a detailed understanding of the threat landscape at both user and system levels, Graylog enables organizations to make more informed decisions about their security posture and respond more effectively to potential threats.

Exclusive to Graylog is its native advanced data routing that enables practitioners to send lower-value “standby” data to inexpensive storage before it is indexed by Graylog. Standby data is available for retrieval into Graylog for future incident investigations. This classification shifts the typical SIEM license model to more accurately align with the overall value of the data. Security and IT operations teams can now invest time and money in the value of the data sent, processed, and stored while minimizing the number of technology solutions managed.

“A challenge with SIEMs has been the need to bring in all the data from log sources as if all the log messages are of equal value,” said Seth Goldhammer, vice president of product management at Graylog. “Of course, if a log message is dropped, it is gone forever. Our new data routing removes this compromise, allowing practitioners to bring in all the data and only pay for the log messages delivering value.” 

Graylog’s asset-based risk modeling finds related security events across attack surfaces and prioritizes what should be investigated with context such as vulnerability state, variance, and API risk. Instead of thousands of daily alerts requiring individual triage and investigation, Graylog prioritizes the high-risk users and systems for security analysts, grouping together multiple alerts and context to expedite the investigation. 

Graylog’s Fall 2024 release includes a timeline visualization of events and leverages GenAI to summarize these details, including impact analysis, into an incident response report to further aid with those investigations and save analyst time.

To learn more about these new capabilities, attend Graylog’s free virtual user conference, Graylog GO, which will be held Oct. 23 – 24. 

Upcoming Graylog GO User Conference to Showcase Graylog’s Award-Winning SIEM Solution

HOUSTON – October 10, 2024 — Graylog, a leader in Threat Detection, Investigation, and Response (TDIR), today announced it has won CyberSecurity Breakthrough’s ‘SIEM Innovation of the Year’ Award. Graylog’s SIEM solution, Graylog Security, is recognized as an innovative, integrated, and user-friendly security solution that delivers exceptional value.  

Graylog’s platform provides a unified approach to threat detection, incident response, and log management. The integration simplifies security operations and enhances efficiency and effectiveness. Graylog’s SIEM solution stood out for its enriched AI/ML capabilities and ability to provide advanced threat detection and real-time monitoring, allowing organizations to stay ahead of sophisticated cyber threats.

SIEM strategy will be a theme throughout the fourth annual Graylog GO User Conference, a two-day virtual event on Wednesday, October 23 and Thursday, October 24. The Graylog GO opening keynote, ‘The Future of SIEM & Log Management – Industry Trends, M&A Activity, and the Role of AI,’ will be presented by renowned EMA cybersecurity industry analyst Chris Steffan. Chris will deliver a comprehensive overview of the state of the SIEM and Log Management industries. 

Graylog GO attendees will also be treated to a closing keynote by Prof. Dr. Marco Gercke, a distinguished entrepreneur, scientist, and advisor, recognized globally as an authority on digitalization and cybersecurity. 

“We are honored to receive the ‘SIEM Innovation of the Year’ Award from the CyberSecurity Breakthrough organization and are excited to highlight our SIEM innovations at Graylog GO 2024,” said Andy Grolnick, CEO of Graylog. “We have demonstrated that our SIEM solution breaks through the crowded cybersecurity industry to meet the security needs of the modern enterprise. Our SIEM is at the forefront in providing innovation, usability, and scalability – cost-effectively.”

Graylog was also named a leader and fast mover in GigaOm’s 2024 SIEM Radar Report. Graylog Security was applauded for innovation, flexibility, and comprehensive Threat Detection. Additional 2024 Graylog award wins for SIEM include:

• The Global InfoSec Awards: Editor’s Choice SIEM Award
• The Globee Awards for Cybersecurity: Gold SIEM Award Winner 
• Cybersecurity Excellence Awards for SIEM

To learn more about  Graylog’s award-winning SIEM during the Graylog GO User Conference register at Graylog GO.