Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Logging in the BS2000 system

&pagelevel(2)&pagelevel

In the BS2000 operating system, as in any other operating system, it is ensured that system administration is informed of all relevant events. Such events may be triggered by hardware and/or software, as well as by user actions or automated processes.

All of these events are logged within the system by different components and in various files. In BS2000, examples include SAT, ACCOUNTING, and CONSLOG. Depending on the logging component, events are therefore recorded in different formats, for instance, in a binary format for SAT, or in a printable message format for CONSLOG.

The diagram below illustrates the typical flow of information logging that are relevant for evaluation in the BS2000 operating system.

Logging in BS2000 OS


The quantity of events produced by an operating system during operation may be substantial. Therefore, filtration and pre-selection methods are utilized in specific logging tools and are documented in the BS2000 documentation.

The CLIP subsystem in BS2000 provides a unified interface that collects security-relevant BS2000 messages and events produced by different components, maps them to the standardized Syslog protocol format and forwards them to an external server, such as an rSyslog server, for further processing. From there, they can be routed to a central SIEM system for analysis.

In the current version of CLIP, the following BS2000 events are supported and made available for external analysis:

  • SAT (Security Audit Trail)

  • ACCOUNTING (Accounting Records)

In the example scenario shown below, rSyslog servers are used to illustrate the setup. These servers receive and store events from multiple BS2000 systems. The rSyslog servers themselves can also be cascaded, meaning they can forward the received events to a central rSyslog server, which aggregates all events. This central server can then pass the data on to a SIEM instance for further analysis. The scenario demonstrates the scalability of the infrastructure.