Firewall design and implementation generally require the presence of a subsystem that is responsible for accountability. This subsystem stores information on user and administrator activities performed on or through the firewall and must be configurable to provide exactly the amount and type of information needed which, on the other hand, is usually defined by the corporate IT Security policy.

This requirement in computer systems is typically fulfilled by a logging subsystem. Logging is the act of collecting information about events in the system. The result of logging can be the following.

These log files are archived for event–tracking purposes. Apart from a simple, automated archiving procedure, however, these log files must be continuously analyzed. Logging records user and system activities in (quasi) real-time, so a continuous analysis is capable of detecting malicious user activities or system malfunctions as they happen, thereby allowing for an effective and quick response policy.

In security-sensible systems, such as the PNS firewall, logging must be a system–wide action, that is, all the relevant components of the system provide logging information, or log entries. Then, there must also be a central component, a logging subsystem, that collects log entries from the various system components and organizes them into a log file of some format (the term file is used literally here and does not necessarily mean a text or binary file: it is simply the output of logging that can be a database, the console or some input queue on another machine). It would not be practical nor economical for all the components to manage their own log files. It would waste system resources (more open file handles, database connections or network sessions, depending on the output destination used) and would make analysis cumbersome (hunting for information in several separate log files that would probably be syntactically incompatible).

In PNS, centralization is elevated to a higher level: the logs of the central logging subsystem on all machines are unified on a network–wide dedicated central logging machine. This way log analysis, reporting and archiving is simpler even for larger networks with many entities providing logging capabilities.

These requirements have, in part, long been targeted by the Unix syslog subsystem. For decades, syslog was the ultimate central logging subsystem for Unix and Linux machines. It is an old and rather unreliable technology and lacks some flexibility and security features that are required in today's demanding network and security environments. Therefore, a replacement service called syslog-ng, where "ng" stands for "next generation", has been created. The syslog-ng application inherited all the concepts, features and most of the naming conventions from syslog and enhanced it with several new features targeting flexibility and security requirements. PNS uses syslog-ng as its logging subsystem.

The following sections include a short introduction to the concepts of syslog-ng, and describe how MS works with syslog-ng and how this subsystem can be managed with MC.