Below is the list of blog posts with the “Telemetry collection” tag.

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 choice here is not between two interchangeable log tools. It is a choice about where you want parsing, routing, and failure handling to live. Filebeat runs close to the source and keeps collection small. Logstash sits in the middle of the flow and takes on filtering, enrichment, and fan-out. That architectural difference matters more than a feature checklist. Pick the narrower tool when your logs have one destination and your parsing rules are modest.

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.

Centralized log management is the practice of collecting logs from across an environment, including applications, servers, containers, networks, and cloud services, and storing them in a single location where they can be searched and analyzed. For operations and security teams, centralized logging is now a core requirement. Without it, logs are scattered across hosts, ephemeral containers, cloud consoles, and disconnected tools. This fragmentation slows troubleshooting, complicates incident response, and limits visibility during security investigations.

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.

An excellent way to get started in a new technology area or refresh our knowledge is to devise a solution based on a small idea or need. This blog post covers such a situation, with a small personal project demonstrating how to use NXLog’s powerful features. I embarked on a small pet project centered around a cloud machine running Debian 10. It connects telemetry from my home, country house, and notebook.

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?

Event logs are our breakfast, lunch, and dinner at NXLog. Before NXLog, I worked on an API that collected software usage logs. And before that, on a centralized log management application. Today, after a career of dealing with logs, I wondered, "How did our world come to rely so much on event logging?" I mean, in the vast landscape of technological progress, the history of event logging is only a minor subplot.

The U.S. Federal Trade Commission (FTC) approved amendments to its Safeguards Rule that require FTC-regulated non-banking financial institutions to report data breaches and other security events directly to the FTC. It was originally proposed to add a breach notification requirement back in late 2021. The rule requires financial institutions to report “notification events” to the FTC within 30 days of discovery of the notification event where the private information of 500+ consumers is involved.

Historically, seaports have played a crucial role in a state’s development, and interruption in their services has a significant impact on economics. So, it’s no surprise commercial ports are regarded as a critical transport infrastructure. One of the most significant challenges ports face today is ongoing digital transformation. The majority of tasks carried out across a port utilize autonomous and partially automated systems, including those for managing port access, vessel berthing (bridges, locks, gates, etc.

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.

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.

So, it happened again. You got an internal audit finding or a regulatory notice. Or you just had a nagging feeling and found customer data somewhere it shouldn’t have been. Morale sinks. Are you forced to choose between serving your customers and addressing compliance weaknesses? Nobody said IT Compliance was easy. But don’t sign up to do any more work than is necessary. Use Frameworks to identify the activities, like logging, that demonstrate compliance for multiple domains and get the absolute best coverage without extra work.

The Windows DNS debug log contains valuable information on DNS queries and activity that is especially useful for monitoring and analyzing malicious traffic. This requires some configuration changes for the DNS service in order to enable debug logging. Here is a short description on how to enable debug logging for the DNS service on windows, this also applies to Windows Server 2008 and later. It is possible to specify the file and path name of the DNS debug log file as well as the maximum size of the file.

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.

Compliance mandates are frameworks that organizations must implement to meet industry regulations. Some of these mandates provide guidelines and best practices, while others may be tied to legislation. With the constant and rapid changes in technology, ensuring that your organization adheres to the relevant regulations is an ongoing process. So why should you comply? Simply put, not complying might cost you more than implementing processes to meet regulatory requirements. By not complying, you might be violating the law, and in case of a data breach, you may face litigation from affected parties.

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.

Unquestionably, Microsoft Windows is the number one desktop operating system in the world, as well as having a significant share of the server operating system market. Multi-million-dollar organizations rely heavily on Windows Server and Active Directory to provide a safe, secure networked environment for their business operations. Such an enterprise infrastructure alone can generate thousands of events per second that range anywhere from benign user authentication events to logs indicating a severe software failure, or even more serious events such as DoS attacks or intrusion attempts.

Modbus is a simple and flexible protocol used by a wide variety of industrial and automation equipment. Its simplicity has made it attractive for many manufacturers, but it also poses a number of challenges in terms of security and traffic analysis. In this post, we’ll show you how to use NXLog to capture, process, and extract useful security information from Modbus traffic. What makes Modbus traffic analysis challenging? Modbus is a low-level protocol that effectively uses only two data types: bits (in the form of coils), and 16-bit words (in the form of registers), which are also the only form of data that can be natively addressed with most devices.

Windows Event Forwarding (WEF) is a service available on Microsoft Windows platforms which enables the forwarding of events from Windows Event Log to a central Windows Event Collector. Since the technology is built into the operating system, this means you can centralize log collection without having to install third party software on each Windows node. You can also use Group Policy for configuring clients to forward their events. This approach not only standardizes client management but also streamlines it.

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.

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.

One of the harder decisions revolve around implementing agent-based vs agentless log collection. This post covers the two methods - their advantages and disadvantages - and provides some quick and actionable implementation notes. Why does log collection agent choice matter? When deploying a log collection strategy, administrators usually tend to zone in on already selected solutions that answers fundamental questions, such as "Will this solution collect and ship these types of log sources?