Modular Semantic Schema Mapping for Heterogeneous Security Syslogs: Deployability and Cross-Vendor Robustness
This paper proposes a modular, three-stage pipeline for mapping heterogeneous security syslogs to a common schema, demonstrating through extensive evaluation on Korean education-sector data that combining structural canonicalization with both local and agent-based semantic matchers significantly improves mapping accuracy while revealing a critical trade-off between precision and deployment latency across different vendor environments.
Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer
In the digital nervous system of modern organizations, security teams rely on a constant stream of automated reports known as system logs. These logs are the digital footprints left by firewalls, servers, and network devices as they monitor for threats. For a security team to make sense of this flood of information, they need to translate these reports into a single, unified language. Imagine a room full of people trying to discuss a fire, but one person calls it a "blaze," another a "conflagration," and a third "heat event," while they all describe the location using different street names and building numbers. Without a shared vocabulary, the conversation fails. In the world of cybersecurity, this shared vocabulary is called a schema. When different security products from different manufacturers generate logs, they often use their own unique names and structures for the same basic concepts, creating a chaotic barrier that prevents automated systems from analyzing the data effectively.
A team of researchers at Hongik University in South Korea has tackled this problem by developing a new method to translate these conflicting security reports into a common language. Their work focuses on the massive network of educational institutions across Korea, where thousands of different security devices from various vendors generate millions of alerts daily. The researchers found that simply trying to force a single artificial intelligence model to solve the entire translation problem at once was inefficient and often impractical for real-world use. Instead, they broke the task down into a three-step process that acts like a specialized assembly line. First, they clean up the messy field names and structures. Second, they use a matching tool to find the correct meaning. Third, they score the match to decide how confident they should be in the result. This modular approach allows security teams to choose the right tool for their specific needs, balancing speed with accuracy.
The core of their solution is a new way of organizing the data before it is even analyzed. The researchers created a standard format they call a Normalized Mapping Object. Think of this as taking a complex, handwritten note and rewriting it into a strict, three-part form: the name of the item, what kind of thing it is, and where it sits in the hierarchy of the system. By forcing every piece of data into this rigid structure, the researchers removed the confusion caused by different manufacturers using different names for the same thing. They tested this method on a massive dataset derived from hundreds of documents describing the logs of security devices used by schools and universities. The dataset included one thousand source fields and one thousand target fields, representing the complex web of connections that security analysts must manage.
When they applied this standardized format to their matching tools, the results were immediate and significant. They tested two different types of matching engines: one that runs locally on a computer using a compact, efficient model, and another that uses a more powerful, cloud-based artificial intelligence agent. Without the new standard format, the local model could only correctly identify the right match about half the time. With the new format, its accuracy jumped to over seventy percent. The powerful cloud-based agent also improved, rising from roughly seventy-eight percent to over eighty-five percent accuracy. This proved that the value of their work lay not just in the matching tool itself, but in the way they prepared the data for it. The standardized format made the job easier for both the simple and the complex tools.
The researchers then compared the two matching engines to see which one was better for a real security operation. The cloud-based agent was slightly more accurate at finding the single best match, getting it right about eighty-six percent of the time. However, it was incredibly slow, taking nearly twenty-six seconds to process a single field. In a security center where thousands of alerts arrive every minute, a delay of that length is unacceptable. The local model, by contrast, was much faster, processing a field in just one and a half seconds. While it was slightly less accurate at picking the very top match, it was excellent at providing a short list of the best five candidates. In fact, it found the correct answer within the top five choices more often than the slower agent did. This revealed a crucial trade-off: the faster, local tool is nearly as good at giving a security analyst a short list to review, but it does so almost instantly and without needing to send data to an external service.
To ensure their system was robust, the researchers tested it against real-world variations, including different vendors who use their own unique names for standard features. They focused on web application firewalls from three different manufacturers. Even when the system had never seen the specific names used by a new vendor before, the local model could still map the fields correctly about eighty-three percent of the time when a standard target was available. When they tried to use knowledge from one vendor to help map a completely different vendor, the accuracy remained high at roughly seventy-eight percent. This suggests that the system can handle the messy reality of the market, where new devices and different naming conventions appear constantly. The researchers also measured how long each step took, confirming that the local method is fast enough to run on standard office hardware without relying on expensive cloud services.
The study concludes that there is no single "best" way to solve this problem for every situation. Instead, the best approach depends on the specific constraints of the security team. If the priority is finding the absolute perfect match and speed is not an issue, the powerful cloud agent is the better choice. However, for most security operations centers that need to process data quickly and keep it within their own secure networks, the local model offers a compelling alternative. It provides a high level of accuracy, especially when analysts are willing to review a short list of top candidates, and it does so with a speed that makes real-time monitoring possible. The researchers propose a hybrid strategy where the fast local model handles the majority of the work, and only the most difficult or uncertain cases are sent to the slower, more powerful agent. This approach allows organizations to maintain high security standards without getting bogged down by the sheer volume and variety of data they must manage.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.