Application Security Monitoring

As a system administrator you have the possibility to control all the user interactions (events) in imperia CMS. The function of Application Security Monitoring is to write the user interactions into a logfile. For this purpose you have a LEEF logger provided. The LEEF logger can be used by the plug-ins to store information in the LEEF format, which can be read by QRADAR.

You can use/ program event-plug-ins, which serve as an access point to react to certain events of controllers. With other words, a plug-in defines to which events it responds.

In LEEF configuration it is defined, which event-independent information or data is transferred to the LEEF logger and finally written into the log file as a LEEF format.

Examples for interactions (events) are:

user x changes the data of user y.
user x starts Hermes.

Logger plug-in#

You will find the logger plug-in under site/modules/core.

Following information has to be included in the plug-in:

Specification of the package path:

package Dynamic::Router::YourEventPlugin;

Your plug-in should be derived from the class Imperia::Router::Plugin:
```
use base qw(Imperia::Router::Plugin);
```
Methods: filter

The method filter specifies which requests are to be logged on a controller.

Example for activation of Hermes:

        sub filter {
            my ($self, $class, $imperia) = @_;
            if ($imperia->request->method eq 'GET') {
            $imperia->payload->{imperia}{__callback} = sub {
                $self->{logger}->logEvent({header_eventid => 'change proc', 
                                    msg => 'Process was changed',
                                    $self->getUserInfo(),
                                });
            };
            }
        }

The event is written to the log file Using callback

    $imperia->payload->{imperia}{__callback} = sub {
    $self->{logger}->logEvent({header_eventid => 'change proc', 
                    msg => 'Process was changed',
                    $self->getUserInfo(),
                });
    };

You can identify which user triggered the request by using $self->getUserInfo().
Provided that additional parameters are given, it is possible to identify, whether it is a deletion, storing process or a patch by using the variable $imperia->request->imperiaPathInf

For example an user has been deleted:

        my ($command, $id) = $imperia->request->imperiaPathInfo;

        if($command eq 'delete' && $id) { 
            do something ...
        }

To be able to react to a specific controller, it must be specified in

getRegistered Controller

For example the Hermes activation should be logged:

        sub getRegisteredController {
            my ($self) = @_;

            return ('Imperia::Controller::System::Hermes::Control');
        }

Event plug-in#

You will find the event plug-ins under: site/modules/core/Dynamic/Router.

Following information has to be included in the plug-in:

Specification of the package path:

package Dynamic::Router::YourEventPlugin;

Your plug-in should be derived from the class Imperia::Router::Plugin:
```
use base qw(Imperia::Router::Plugin);
```

The controllers to which the plug-in responds, has to be returned to:

getRegisteredController

An example for activation of Hermes should be logged as follows:

    sub getRegisteredController {
            my ($self) = @_;

            return ('Imperia::Controller::System::Hermes::Control');
    }

Additional methods:
```
filter
```

Every request is transmitted to the filter method. Here, you can decide which requests have to be logged on a controller.

An example for activation of Hermes:

    sub filter {
        my ($self, $class, $imperia) = @_;
        my $file = 'site_hermes_unix.pl';
        if ($imperia->request->method eq 'GET') {
        $imperia->payload->{imperia}{__callback} = sub { 
            my $response = $imperia->response->{_content};
            if($response =~/Permission denied/){
            $self->{logger}->logEvent({header_eventid => "change proc", 
                                        msg => "Access denied to $file",
                                        file => $file,
                                        $self->getUserInfo(),
                                    });
        } else {
            $self->{logger}->logEvent({header_eventid => "change proc", 
                                        msg => "Process $file was changed",
                                        file => $file,
                                        $self->getUserInfo(),
                                    });
            }
        }
    }

After the request.

In the variable $imperia->payload->{imperia}{__callback} you can enter the code which should be executed after the processing of the request. In the above example, the event is written to the log file, where the variables are to be filled with corresponding values.

      $imperia->payload->{imperia}{__callback} = sub {
        $self->{logger}->logEvent({header_eventid => 'change proc',
                            msg => 'Process was changed',
                            file => $file,
                            $self->getUserInfo(),
                        });
        };

With the variable $self->getUserInfo() can be identified which user has activated the request.

With the variable $imperia->request->imperiaPathInfo- as long as additional parameters are given- it is possible to identify, whether it is a deletion, storing process or a patch.

    A case example might be "a user has been deleted":

    my ($command, $id) = $imperia->request->imperiaPathInfo;

        if($command eq 'delete' && $id) {
        do something ...
        }

Log file (LEEF file)#

The LEEF file displays information depending on which fields are configured. This information is shown in Table 2. LEEF format descriptions.

Note

Fields that do not apply, remain empty, e. g. "file=". Character Encoding UTF-8 must be used for LEEF events.

Configuration#

You find the configuration file as a sample under site/config/leef.conf.sample. It can be used as a template for own configurations. If you use the LEEF logger, you will have to use the customised configuration.

It is used to configure the fields, which are located under<base> and which values are taken from the plug-in.

The header data that is displayed in the LEEF file is also specified there.

To define the location for the leef.log, use the logfilename.

Enter the IPv4-address in the configuration file under header_systemIP to get it displayed in the syslog-header.

Example 1:

header_systemIP = 127.0.0.1

Enter the proper LEEF format under header_format.

Example 2:

header_system = LEEF:1:0

An example for a configuration could look as follows:

    logfilename = /tmp/leef.log
    <base>
        header_systemIP = 127.0.0.1
            header_format = LEEF:1.0
            header_vendor = pirobase imperia gmbh
            header_version = imperia CMS|11
            env = E
            cat = 
            usrName = 
            usrName2 = 
            file = 
            msg = 
            src = 
            dst = 
            srcPort = 
            dstPort = 
            sev = 
            par1 = 
            par2 = 
            role = 
            grpName = 
            role2 = 
            grpName2 = 
          </base>

The fields with the prefix header_ form the syslog header as well as the LEEF header. The fields without the prefix form the predefined or customised attributes of the events.