Below is the list of blog posts with the “security” category.

Most Windows detection programs are anchored on a small set of well-known event IDs: 4624, 4625, maybe 4688 if process creation auditing is turned on. The events that actually describe an intrusion (the new service, the scheduled task, the explicit credential, the share enumeration) live elsewhere on the same host, often on channels that are not enabled by default. We have written before about why a 4625-only mindset leaves most of the attack chain in the dark; this post is the catalog that picks up where that argument ended.

The default advice for any system running an unsupported operating system is simple: replace it. Upgrade to a supported platform. Move to modern hardware. Problem solved. It’s good advice in theory. As with many other things in life however, in practice it ignores everything that makes legacy infrastructure hard to deal with in the first place. For organizations running Windows XP, Server 2003, or other legacy 32-bit Windows systems, "just upgrade" is often the most expensive, disruptive, and operationally risky option on the table.

Compliance frameworks don’t have a checkbox for "we know it’s a problem, but we can’t afford to fix it right now." Yet that’s the position thousands of organizations find themselves in — bound by regulation to meet security standards that their operating systems are physically incapable of supporting. If you run Windows XP, Server 2003, or any other unsupported OS in a regulated environment, the compliance obligation doesn’t go away just because the upgrade path is blocked.

Somewhere in a hospital basement, an MRI machine hums along on Windows XP. Down the road, a CNC controller on a factory floor runs Windows Server 2003. Across town, a municipal utility manages water treatment with software that hasn’t seen an update since the second Bush administration. These aren’t edge cases. They’re everywhere — and they represent one of the most underestimated risks in enterprise security today. Still here, still running It would be reasonable to assume that operating systems from the early 2000s have no place in a modern network.

Why the federal agency breach shows that standardized telemetry formats aren’t optional anymore When CISA analyzed the federal agency breach that went undetected for three weeks, they identified a familiar pattern: EDR alerts existed but weren’t continuously reviewed. Security teams had visibility tools, but critical signals got lost in the noise. What the advisory doesn’t detail—​but every security practitioner knows—​is the infrastructure nightmare hiding behind that simple statement. Those unreviewed alerts likely came from dozens of sources, each speaking its own dialect of security telemetry.

The SentinelOne outage showed why visibility isn’t optional—​even when your defenses keep running. On May 29, 2025, organizations running SentinelOne experienced something unsettling: their security controls kept working, but they couldn’t see what was happening. A software flaw in SentinelOne’s infrastructure control system caused a global service disruption that lasted several hours. According to reports, the incident significantly impacted customers' ability to manage their security operations and access important data.

How a federal agency’s monitoring gaps turned a containable incident into a three-week nightmare In September 2025, CISA responded to a federal agency breach that security teams could have stopped in hours. Instead, threat actors roamed the network undetected for three weeks. The damage? Multiple compromised servers, web shells planted across the infrastructure, and a persistent foothold that took significant resources to remediate. The root cause wasn’t a zero-day exploit or sophisticated malware.

From years of supporting NXLog Agent deployments across many environments, we’ve learned that while Linux generates a wealth of security logging, much of it remains underutilized. Critical security events are buried across multiple log files and subsystems, making it more complicated than it should be to spot suspicious activity. Efficient Linux security logging requires knowledge of which events matter and where to get them. Authentication attempts, privilege changes, package installations, audit events, and system shutdown events can all tell a story when viewed together.

We are committed to the security of our customers, and wish to inform you of CVE-2025-67900, a recently published vulnerability affecting the Windows version of NXLog Agent 6.10 and older. Technical description The Windows version of NXLog Agent 6.10.10368 and older includes a Privilege Escalation vulnerability because it attempts to load an OpenSSL configuration file from the hardcoded and unintended directory C:\nxlog4\x64\ on startup. This is a legacy installation directory that may not exist in clean NXLog Agent installations.

Imagine a typical company: employees join, they move between offices and departments, then they leave. Each of these changes requires a systems access update for email, databases, internal tools, and more. Manually managing these transitions can be burdensome and error-prone. And where you have errors, you have inefficiencies and exposure to security breaches — neither of which is good for your business. This is where Identity and Access Management (IAM) comes in.

Timely visibility into system activity is what separates effective defense from reactive analysis. Every operating system, application, and device logs a trail of evidence. However, transforming that trail into actionable intelligence requires the right tools. In our previous posts, we’ve walked you through: Visualizing VPN connection logs, Monitoring Windows security events, and Analyzing web server activity logs. In this final installment in our series on log visualization, we’re turning our attention to Linux security monitoring.

When users start reporting slow responses or intermittent errors from your web applications, your first go-to is your web server logs. But did you know those same logs can provide more than just troubleshooting clues? When analyzed with the right tools, they give system administrators and DevOps teams real-time visibility into your web environment, enabling them to monitor web servers proactively, rather than reactively. In this post, we’re going to show you how you can uncover web server performance issues and potential attacks early on by collecting NGINX access logs with NXLog Agent, transforming them into Prometheus metrics, and visualizing them with Grafana.

In our previous blog post, From network logs to insights: Visualizing OpenVPN logs with Elasticsearch and Kibana, we explored how you can gain visibility into VPN activity by collecting and analyzing network logs. Windows security monitoring is another common use case we encounter at NXLog. Windows workstations and servers generate security event logs ranging from authentication attempts and privilege escalations to policy changes and process executions. Such events can reveal external intrusions and insider threats, and for security analysts, they are the first line of evidence in investigating suspicious activity.

At NXLog, we help customers solve real-world telemetry data challenges and bring value to the table with NXLog Platform. One of the recurring problems we see is that while network event logs contain a wealth of information, turning them into actionable insights isn’t straightforward. Security operations teams often struggle to make sense of these logs in a way that directly supports threat detection, response, and investigation. A perfect example of this challenge is VPN logs.

Understanding security event logs for stronger cybersecurity. Whether a multinational corporation or a small business, organizations face ever-increasing risks of data theft, insider threats, and system intrusions. In 2025, the security landscape is further complicated by the growing influence of artificial intelligence, as cybercriminals are leveraging AI to enhance the sophistication and scale of attacks. One of the most powerful tools for detecting and responding to attacks is the humble security event logs.

Most corporate environments require a login, and Identity and Access Management (IAM) is a solution that helps manage that process in different ways. IAM ensures that only the necessary people can access the relevant IT resources. Each user, device or service is assigned a unique digital identity. So, when an employee logs into a company system, IAM confirms that person’s identity. This might involve a login/password check, multi-factor authentication, or both.

Nation-state-sponsored hacking stories are everyone’s favorite Hollywood movies — until our personal or corporate sensitive data shows up on the dark web for sale, being compromised. In real life, cyber espionage groups’s activities trigger security enforcement. First in the government sector, then the government standards slowly shift industry norms starting by gently forcing vendors who are also selling into government contracts. In the case of the recently announced playbook on MICROSOFT EXPANDED CLOUD LOGS IMPLEMENTATION PLAYBOOK, issued by the US Cybersecurity and Infrastructure Security Agency (CISA), it all started in July 2023, when the Chinese cyber espionage group Storm-0558 exploited a vulnerability in Microsoft’s Outlook email system to gain unauthorized access to email accounts belonging to U.

Monitoring and centralizing Remote Desktop logs is critical for IT security, compliance, and operational efficiency, and NXLog Platform makes it simple and scalable. Remote Desktop Protocol (RDP) is a powerful Windows feature that allows users to access a computer remotely over the network. While convenient and widely used, it’s also a potential entry point for attackers. Understanding how to check and analyze RDP connection logs can help detect unauthorized access, troubleshoot issues, and maintain system integrity.

With an ever-expanding choice of technologies on the market, navigating the range of open-source observability tools can be a challenge. Which is why, when it comes to managing complex multicloud environments and their services, standardization is crucial. Here’s where OpenTelemetry (OTel) can play a key role. Developed through the merger of OpenCensus and OpenTracing, OpenTelemetry has become the new standard for open-source telemetry. Discover what OTel is, the types of telemetry data it encompasses, its potential benefits, and how NXLog can support your OpenTelemetry ecosystem.

Back in the day, Gordon Moore made relatively accurate observations and projections about the exponential growth of transistors on semiconductors. It still amazes me, yet very few predicted the incredible growth of system interconnectedness and the vast amount of data it generates. It is estimated that 90% of all data was created in the last two years. Given that everything is connected, the need for telemetry is growing at an unprecedented rate, and so is the need to efficiently channel and manage telemetry data.

Automatic updates are recommended by many vendors as they are considered essential for safeguarding against security threats and maintaining system performance. Updates not only enhance security but also deliver bug fixes and new features, contributing to improved user experience. Software updates, however, come with the inherent risk of breaking existing functionality and can potentially interfere with other software or the operating system itself causing unintended side effects. Automatic updates that the user has no control over escalate the risk further.

Did you know the European Union created a rule called the NIS Directive? This rule was established in 2016 to ensure that all member countries are equally protected against cyber attacks. It’s a step towards making it easier for governments to work together to stop cyber threats. However, the Directive was expected to provide more specific instructions for protecting against attacks and ensuring all countries follow the rule. The rule also requires companies and governments to be better prepared to handle cyber attacks and have a plan in case something goes wrong.

For those of us who manage network authentication and authorization, RADIUS is a familiar term. This protocol was introduced in the last century, and many of us from those days still remember the old-school diagrams, which surprisingly remain on the Cisco Systems website today. Figure 1. Interaction between dial-in user requests, the RADIUS client and server © Cisco RADIUS, which stands for Remote Authentication Dial-In User Service, was developed to address a specific challenge.

In an increasingly digitalized world, protecting your business’s digital assets is becoming more urgent by the day. Realizing the need to protect data from malicious actors, researchers created encryption. And I am not talking about the Enigma here, but software-based encryption algorithms, with their public and private signing keys, and so on. Like every other technology, encryption methods have evolved throughout the years. However, the goal remained the same: encryption is there to secure our digital communications.

I always wondered what happens to our software when a company purchases it. Okay, I know they will install it and use it. But where do they install it? On what kind of machines? In what kind of environment? And why is it important for them to collect and handle logs? The possibilities are endless. We have customers worldwide; from shoemakers to telecom companies, NXLog is everywhere. But where are the most remarkable places NXLog Agent is employed?

European electric power system operators supply around 2800 TWh of electricity per year and manage around 10 million kilometers of power lines - more than ten round trips to the Moon. Such electric travel is impossible without electric substations, an essential component of a power grid. Its automation becomes ultimately digitalized, so requires proper monitoring both for operational and security purposes. Let’s take a look at how a unified log collection pipeline embeds into power automation systems and helps make sure the lights stay on.

Since the Wright brothers' first flight, the aviation industry has been advancing at an unprecedented rate. But it has always been a step behind other sectors in some areas, for safety and security reasons. Engineers are only allowed to apply well-matured technologies thoroughly trialed in different industries. Civil aviation, especially from the IT and IT security perspective, is a bit like Debian among the Linux operating systems. It does not always include all the latest inventions, but it aims to be safe and very stable in return.

The analysis of events produced by various systems and applications can offer insights into the infrastructure health and the operational resilience of an enterprise. From an Infosec perspective, the end-goals are: threat detection, forensics and remediation. However, we can’t query or analyse data that we haven’t collected in the first place! Before threat hunting and incident response are even possible, security events need to be collected from various sources, parsed, transformed, and then forwarded to data sinks such as security information and event managements (SIEM), security analytics platforms, cloud ecosystems and long term storage.

The U.S. Health Insurance Portability and Accountability Act (HIPAA) was introduced in 1996 to protect the privacy and security of health information. HIPAA’s Privacy, Security, and Breach Notification rules require healthcare providers and their partners to protect electronic protected health information (ePHI) through robust access controls, breach reporting, and documentation practices. A critical part of this compliance effort involves maintaining detailed audit logs that track who accessed, modified, or disclosed PHI, and retaining HIPAA logs for at least six years.

In Feb 2021, a major cybersecurity incident was declared when a hacker gained malicious access to the water treatment system of Oldsmar, Florida. Officials said the hacker tried to increase the level of sodium hydroxide in the city’s water supply, putting thousands at risk of being poisoned. Fortunately, it was quickly confirmed that this potential terroristic act did not come to fruition. Two years later, we still have no details on the malicious actor.

Have you ever locked yourself out of your car? After calling for roadside service, your tow truck driver forces the internal locking mechanism open with a slim-jim. Car thieves quickly discovered this technique and began using it to steal cars. Digital thieves have devised a similar attack called a Blind Return-Oriented Programming (Blind ROP, or just BROP) attack. It’s as quiet as a jackhammer on cement, but an attacker can open a remote shell and gain remote code execution on your server if the conditions are right.

The three characteristics your data must possess at all times, as dictated by your IT Security Policy, are: It must be confidential It must be available and It must not have any unauthorized modifications Your log policy will only be as good as the IT Security policy infrastructure behind it. And as much as we love talking about logs, that’s part of a more considerable general discussion about security policies.

Log collection is essential to managing an IT department because it allows administrators to research historical events throughout a network. Therefore, it’s critical to understand a few key points about collecting logs; the why, and what. We’ll look at a few specific examples of collecting log events efficiently, like incorporating threat modeling to enhance our collection. Implementing log collection policies and procedures is as fun as watching anti-phishing videos. But at the end of the day, the effort put in at the beginning will be worth it.

With open war in Europe for the first time since 1945, nations across the continent have been busy shoring up their information security defenses. The European Union is stepping up to the plate, releasing a Cyber Defence Policy to, in its words, "boost EU cyber defence capabilities and strengthen coordination and cooperation between the military and civilian cyber communities." However, bolstering cyber defenses across a collection of countries, home to 450 million people and spanning four million square kilometers, is no easy feat.

Cybersecurity Awareness Month has come and gone again. October marks that festive time of year when companies circulate their mandatory think pieces, remind their employees of the dangers of clicking questionable links, and pat themselves on the back and call it a day. Here’s your friendly November reminder to keep your wits about you year-round. A (brief) history of Cybersecurity Awareness Month The Cybersecurity Awareness Month story began as a partnership between an American governmental agency—​the Cybersecurity and Infrastructure Agency (CISA)--and the National Cyber Security Alliance non-profit.

Industrial Control Systems (ICS) have evolved over the years and now have a lot in common with traditional IT systems. Low-cost Ethernet and IP devices are replacing older, proprietary technology, which opens up new possibilities to improve connectivity and remote access. However, it also increases vulnerability to cyberattacks and incidents since the system is no longer segregated. Due to the nature of ICS, they differ from other IT systems. A compromised system can cause severe damage to the environment, incur substantial financial and production losses, and negatively impact an entire nation.

NXLog is a versatile log collector that easily integrates with other software, platforms, and programming languages. Out-of-the-box it supports integration with many third-party solutions through its input, output, and extension modules. Moreover, extending NXLog with custom functionality is as easy as writing an application or script in your favorite programming language and loading it from the configuration. Email notifications of events indicating potential security breaches or severe application errors are a standard procedure for IT admins and DevOps engineers.

As a security administrator, you may be inclined to focus on the Windows Security log within Windows Event Log. You might even go as far as filtering for specific event IDs, such as EventID 4625 (failed logon request), while forgetting there is much more to security logging on Windows than this single log source. The consequence of this narrow field of view is that you are not benefitting from the valuable information that other Event IDs used for security audit policies can offer.

It is known that measuring performance is one of the most challenging tasks in system administration. It requires proper configuration and a good understanding of the results. Fortunately, Linux systems offer a wide variety of tools for obtaining performance metrics. In this blog post, we will focus on the instrumentation capabilities of the Linux kernel and some interesting methods of analyzing the results. The importance of the kernel lies in the fact that usage information related to CPU, memory, disk space, or network interfaces is always passing through it, and it cannot be bypassed.

In light of recent news stories about possible cyberattacks on the U.S. power grid, we are inclined to ponder over precautions we can take to prepare for such a scenario. If you are in the public utilities industry, this blog post is for you. But, if you’re not, don’t worry. We will cover some basic principles you can follow to get your organization ready before such a cyberattack occurs.

The Apache Log4j vulnerability has attracted a lot of media attention as a result of recent security incidents that were reported by some organizations using versions 2.0-beta9 through 2.14.1. This security flaw has the potential to affect thousands of applications since some of the world’s largest databases rely on Log4j. Because so many organizations are affected, cybercriminals are actively exploiting this well-known vulnerability. Why is this so dangerous? In addition to the threat of malware and ransomware, hackers can also perform remote code execution due to the Log4j vulnerability.

DHCP server log collection made simple DHCP (Dynamic Host Configuration Protocol) is a network management protocol that dynamically assigns IP addresses to each client machine on your network. However, its importance does not stop there. DHCP can even generate numerous critical events that indicate your network’s security has been compromised. You might then wonder how you can use these events to safeguard your organization from intrusion. Well, these event logs store valuable information that contain the ID and IP address associated with each client.

Kubernetes is nowadays the de facto standard for the deployment and management of containerized applications. A Kubernetes deployment may contain hundreds, if not thousands, of nodes and pods. As with any other system, collecting logs from your Kubernetes environment is imperative to monitor the health of your cluster and to troubleshoot issues when they arise. In this post we will explore the logging challenges that Kubernetes poses, and how NXLog can be a key player in your logging solution.

File-based logs are where it all began. These logs can yield information of great value to security analysts and administrators alike. Armed with this information, IT professionals are better equipped to troubleshoot issues, evaluate system performance, identify bugs, and even detect security breaches. In today’s world, we tend to focus on the modern, integrated logging facilities like Microsoft’s Windows Event Log or Apple’s Unified Logging System (ULS). However, all the major operating systems still generate log files that may or may not be integrated into these logging facilities.

It goes without saying that across your business infrastructure, there should be a commitment to protect not only the hardware and software assets, but the plethora of data that is transmitted through and stored in it. However, to successfully safeguard such data, it is imperative to have an effective audit policy in place that includes the collection of security events as its essential component. Windows provides a wealth of security logs that are visible in the built-in Security channel of Event Viewer.

The Domain Name System (DNS) facilitates communication between all devices connected to the Internet. It consists of hierarchical servers that can translate any given hostname, along with its corresponding domain name, to its internet protocol (IP) address(es). One of the most common is the windows DNS server that ensures that data requests are sent to their correct endpoints while providing human-readable addresses for websites connected to the Internet. With the ever-growing number of cloud-based devices and technologies, for instance, the Internet of things (IoT), portals, web applications, as well as online transaction processing, it is more important than ever to identify the actual physical addresses of remote devices when relying on DNS-dependent connectivity.

Applications are getting more and more complex. The demand to develop them faster is ever-increasing. This puts stress on organizations’ processes, infrastructure, and the IT teams that support them. Modern Container technology helps to alleviate issues faster across multiple environments. Linux containers are another evolutionary leap in how applications are developed, deployed, and managed. These containers are based on stable Red Hat Enterprise Linux images that have no adverse effects on your current IT infrastructure.

DNS Log Collection and Parsing DNS log collection and parsing should be part of the log collection strategy of every modern IT infrastructure. There are numerous reasons why you should be concerned enough to collect as well as parse the DNS logs collected, some of which include: Operations and Support Parsing DNS server logs can be used to track active DNS clients, while parsing complex and noisy logs can be helpful in troubleshooting support issues.

Be sure to read Part 1 and Part 3 of our DNS Log Collection series, in case you missed them. DNS Log Collection on Windows If you need to reduce the cost of DNS security and increase efficiency through centralizing DNS log collection, where would you start? Answering this question requires knowledge and awareness of the challenges and opportunities available on the Windows platform. While Windows DNS server is a common technology serving many types of organizations, from local domains to large multi-site enterprises, the possibilities are not necessarily that well-known within the context of comprehensive, site-wide log collection.

Be sure to read Part 1 and Part 2 of our series in case you missed them. DNS Log Collection on Linux In the third, closing part of our series on DNS log collection, we discuss DNS logging on Linux using open source software. From the numerous open source DNS server implementations available, we tried to include the more popular ones and summarized what is involved in collecting logs from them.

"The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications." In this article these top security risks discussed in the context of log collection. OWASP API security top 10 most critical API security risks APIs are a critical part of modern technologies - from SaaS and web consumer applications to enterprise deployments.

About File Integrity Monitoring (FIM) File integrity monitoring is implemented as a detection mechanism to monitor changes to important files and folders. File integrity monitoring is largely used as a security measure for detection and for meeting obligations such as compliance. By using file integrity monitoring, better control measures can be taken due to being able to track and provide data for alerts of activities on assets that are being monitored, such as potential unauthorized changes.