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

Most security leaders can tell you their SIEM bill to the dollar. Far fewer can tell you, line by line, what they’re paying for. That’s a problem because in financial services, that bill grows faster than the security coverage it’s supposed to buy. Let’s break it down. The bill is a function of volume, and volume is not your friend Ingestion-priced SIEMs charge by how much data you send. That makes your security budget a direct function of log volume.

Your detections, correlation rules, and search results are only as good as the underlying data structure. A raw log line is a string. A structured JSON event is a set of named fields you can filter, pivot, and alert on. Convert your logs to JSON at the collection layer before they reach your SIEM. Doing it early cuts ingest cost, keeps your schema consistent across sources, and makes your detections less fragile.

Most telemetry pipelines treat every newline as the end of an event. That assumption holds for a tidy syslog stream but breaks the moment a Java stack trace, a Python traceback, or a pretty-printed JSON payload lands in the file. One event becomes forty lines, and your SIEM ingests forty fragments instead of one record. For a SecOps team, the cost is operational. Detection rules match on fragments or miss the event entirely, correlation loses the context that made the event worth alerting on, and the event count balloons against a volume-based license.

Most discussions about OpenTelemetry pipelines focus on getting data from point A to point B. Collect telemetry, maybe convert the format, forward it to a backend. That’s the minimum viable pipeline, and it’s where most tooling stops. But a pipeline that only moves data is a pipe, not a processing layer. The telemetry arriving at your observability platform or SIEM is only as useful as the context it carries. A raw log entry saying "connection from 198.

Logs play a critical role in IT infrastructure, and choosing the right log management solution is key to effective operations. This guide explores the core principles for selecting a solution that aligns with your log collection and management needs. Given the wide range of options available, we categorize them into three main groups for clarity. End-to-end Log Management Solutions Security Information & Event Management (SIEM) Application Performance Monitoring and Observability (APM)

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.

Windows DNS Server log collection is essential yet complex, primarily because Windows DNS Server provides logs in various places in different forms containing a vast amount of information. Nevertheless, we all know that DNS Server log collection is paramount in IT security. Getting it right can be challenging. The Windows DNS Server section in the NXLog Integrations Guides offers a comprehensive guide on collecting log records from a Windows DNS Server.

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.

We are delighted to announce that with the release of NXLog Enterprise Edition 5.5, NXLog provides native support for sending log data to the Google Chronicle threat intelligence platform. About Google Chronicle Google Chronicle is a cloud-native SIEM service provided on the Google Cloud Platform. It allows organizations to normalize, correlate, and analyze their logging data. Chronicle makes threat hunting easy by empowering security experts to investigate logs allowing them to take a holistic approach to threat detection.

Apple has made great strides in recent years, not only with its innovative hardware, but also with incremental improvements to its operating systems. For a number of reasons, Macs have become viable alternatives to PCs in many large corporations. Apple also continues to maintain a strong presence in institutions of higher education, as it has for decades in the US. Whether your Mac users are working on spreadsheets in accounting or they belong to creative teams developing software or marketing content, your digital assets are valuable and need to be monitored to detect any potential security threats.

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.

What if you could selectively ingest only the high-quality events needed for metrics and reporting that come not only from Azure, but also from other cloud- based resources and on-site assets directly into Microsoft Sentinel? In this post, the technology we will be examining is the Azure Monitor HTTP Data Collector API, which enables clients, such as the NXLog agent, to send events to a Log Analytics workspace, making them directly accessible using Microsoft Sentinel queries.

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.

NXLog supports direct collection of Event Tracing for Windows (ETW) data. DNS Analytical logs, for example, can be forwarded to Splunk or another SIEM for monitoring and analysis. Collecting ETW Logs Event Tracing for Windows (ETW) is a kernel-level tracing facility that provides high-performance logging of kernel and application events. ETW events can be written to a log file or collected directly from the system in realtime via the Consumers API.