Why do you want to monitor who accessed a particular file? Files are one of the primary forms of storing information. It is common practice for companies to store data in files that hold valuable, sometimes sensitive, information. What could this "important" data be? Of course, I am not talking about the company’s last team-building pictures. I’m afraid that’s not what the bad guys are interested in. They will likely be more interested in business plans, financial or personal data.

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.

PowerShell scripts can be used with NXLog for generating, processing, and forwarding logs, as well as for generating configuration content. In this article, we will take a look at how to execute PowerShell directly from NXLog. You can run a PowerShell script in multiple NXLog instances without using any PowerShell script file, and is achievable through having the script code directly in NXLog’s exec modules. This is ideal because if you need to make any change to the script, it’s easier to modify just the NXLog module rather than change the script on every computer used.

A multi-factor authentication (MFA) fatigue attack is a form of a social engineering cyberattack strategy where attackers repeatedly try to make second-factor authentication requests to the target’s email, phone, or other registered devices to gain access to the system. You may also hear about MFA Fatigue attack as MFA Bombing, 2FA fatigue, MFA push spam, MFA Spamming, or prompt bombing. Technology administrators are always playing a never-ending battle of cat and mouse when it comes to threat actors.

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.

The global Security Information and Event Management (SIEM) market is big business. In 2022, it was valued at $5.2 billion, with analysts projecting that it will reach $8.5 billion dollars within five years. It’s a highly consolidated market dominated by a few major players in the information security field. They want your business, and they don’t want to lose it. As companies ship more and more data to their respective solutions and make use of more and more features, they become specialized and dependent on a vendor.

There are several reasons you might want to start a particular NXLog module with a delay. You can think of it like delaying the start of a Windows service. In most cases, you need to do this for performance reasons. But there might be other scenarios where you would want to do this, such as collecting logs during a specific time frame. If you have, for example, a less critical module block, you can prioritize the more important one by delaying the less important one.

This post is the first in a series of answers to questions that our customers asked. Clarifying EPS EPS stands for Events Per Second and is considered a standard for measuring the speed of event processing. More precisely, it tells how many events can flow through a particular system in a second. In our case, the number relates to how many events NXLog receives, handles, and outputs in one second.

NXLog supports filtering, enriching, and forwarding logs directly to Splunk Enterprise for further analysis. If you landed on this blog post, you are likely looking for a new log collection solution or seeking to improve an existing Splunk deployment. If so, we hope this article provides you with the necessary information to take the next step toward a better log collection strategy. NXLog and Splunk Universal Forwarder feature comparison Several log collection agents are available on the market, and Splunk Universal Forwarder is one of them.

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.

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.

Logs are a record of the internal workings of a system. Nowadays, organizations can have hundreds and, more regularly, thousands of managed computers, servers, mobile devices, and applications; even refrigerators are generating logs in this Internet of Things era. The result is the production of terabytes of log data—​event logs, network flow logs, and application logs, to name a few—​that must be carefully sorted, analyzed, and stored. Without a log management tool, you would need to manually search through many directories of log files on each system to access and extract meaning from these millions of event logs.

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.

One of the challenges that security-conscious Windows administrators face is collecting and centralizing Windows event logs. One of the obvious solutions that come to mind is the native Windows Event Forwarding (WEF) feature available on all modern Windows operating systems. WEF offers the convenience of forwarding Windows events to a central event collector without installing and managing agents. To objectively portray the role this valuable technology plays in the larger scope of enterprise log collection, we have written several articles that discuss it:

When considering your log collection strategy, a decision you have to make is which transport protocol to use to transfer logs from source to destination. The choice is often between the two most commonly used protocols, UDP (User Datagram Protocol) and TCP (Transfer Control Protocol). Which one to use depends on the type of logs you need to transfer, and whether performance or reliability is more important. This blog post will compare these protocols, discuss why TCP is usually the preferred choice, and provide some options to further increase log delivery reliability with NXLog Enterprise Edition.

How does NXLog Enterprise Edition compare to the IBM QRadar WinCollect event forwarder? IBM QRadar SIEM collects, processes, and aggregates log data to provide real-time monitoring and automated response to network threats. With its powerful correlation engine and specialized modules for risk and vulnerability management, it is no surprise that it is among the highest-rated tools on Gartner Peer Insights. To get the best out of a platform like IBM QRadar, you need to ensure that you send the proper amount of data in a format that it can process efficiently.

If you’re a cyber security enthusiast, you’ve probably heard a lot about Windows Management Instrumentation (WMI) lately. There’s a good reason why this topic has gained popularity, however, this technology has been integrated into Windows operating systems for over 20 years now. In this blog post, we will delve into how WMI works, the risks resulting from misuse, and how to audit it with NXLog. A standardization effort The first thing to clarify about WMI is that it’s not a Windows-only technology.

The value of log aggregation There is no denying the importance of log aggregation for multi-million-dollar enterprises worldwide. But just what is log aggregation? And how can it help your organization? Well, log aggregation is the process of standardizing and consolidating your log data from distributed systems across your network into one centralized server. By doing so, you have a unified view of what occurs across your entire IT infrastructure.

Features of NXLog Enterprise Edition you must have So, it turns out that your organization needs a reliable solution that can collect, parse, forward, and aggregate your log data. This need might be based on any number of reasons. Perhaps it is due to regulatory compliance mandates. Maybe your security analysts have realized that collecting security logs is the best way to detect potential cyber attacks. These are all valid reasons.

In this post, we will look at how to use Raijin Database Engine as a backend in a centralized logging environment for collecting and aggregating Windows security events. We will also show you how to integrate Raijin with an open source data exploration tool. Finally, you will see how you can track suspicious network activity and identify specific types of intrusion on Windows hosts using these tools. A low-cost, lean and mean data discovery solution Although the combination of tools we present here cannot compete with a full-fledged SIEM solution, they do offer quite a few advantages for security analysts who need a responsive, highly customizable data discovery solution that accepts ad hoc SQL.

So, you managed to read through all the compliance mandates that are required for the industry you are in. And, during the mandatory consultation you had with your company’s IT security expert and network manager you came to an agreement on which logs to collect and carefully selected their final destination. Which — in most cases — is usually some kind of analytics system or SIEM technology where log data can be analyzed and stored based on your business requirements.

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.

Data logging, and by extension, logging events have become essential to enterprise-level IT operations in order to provide security and performance monitoring of business operations. However, with the large volume of logs being collected, there is cause for concern that companies are not only collecting too many logs, but also that they are neglecting to collect the very logs that would be most useful for monitoring security-related events. Ironically, many adhere to the notion that the more events collected, the better.

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.

How does NXLog CE and EE compare to the Snare Enterprise Agent? If you are reading this article, you may either be looking for a new log collection agent solution or seeking to replace and improve an existing deployment. This article provides information based on some fairly common questions from those who have migrated from Snare to NXLog. Feature Comparison There are multiple choices of log collection agents available on the market, some are free and have paid versions that come with official support.

IT security should be one of the main focus points of all enterprises. In today’s world, when digital transformation is taking place at an unprecedented pace, securing online data is vital for all kinds of businesses. This is why most companies are utilizing SIEM (Security Information and Event Management) solutions that help them identify threats before they can do any harm. Even though SIEM tools are perfect for event correlation and analytics, it is not part of their core functionality to manage log collection, filtering, distribution, and formatting.

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?

Windows Event Forwarding (WEF) provides log centralization capabilities that are natively supported in Windows-based systems. It is straightforward to set up since it is already built into Windows, and only a few pre-requisites are required, such as having a dedicated event server with a group policy object (GPO). Despite its ease of use and native support, WEF has some limitations. This post covers the advantages of using Windows Event Forwarding for centralized log collection, followed by limitations of WEF and its subsequent solutions.