Application Security Monitoring (ASM)#

Als Systemadministrator haben Sie die Möglichkeit, jegliche User-Interaktionen (Events) in imperia CMS zu überwachen. Mithilfe des Application Security Monitorings werden die User- Interaktionen in eine Logdatei geschrieben. Hierfür wird ein LEEF-Logger bereitgestellt.

Events können zum Beispiel sein :

User X ändert Daten des Users Y.
Hermes wurde von User X gestartet.

Bestandteile des Loggers#

Der LEEF-Logger dient zum Schreiben von Logger-Plug-ins. Dieser kann von den Plug-ins benutzt werden, um die Informationen in dem QRADAR lesbaren LEEF-Format abzulegen. Sie können Event-Plug-ins nutzen bzw. programmieren. Sie dienen als Einstiegspunkt, um auf gewisse Events von Controllern reagieren zu können. Mit anderen Worten, es wird über das Plug-in definiert, auf welche Events reagiert werden soll.

Logger-Plug-in#

Die Logger-Plug-ins liegen unter site/modules/core.

Folgende Informationen sollten im Plug-in enthalten sein:

Package-Pfad angeben

package Dynamic::Router::YourEventPlugin;

Klasse von Imperia::Router::Plugin ableiten
```
use base qw(Imperia::Router::Plugin);
```

Methoden

filter

In der Methode Filter wird angegeben, welche Requests auf einen Controller geloggt werden sollen.
Beispiel Hermes-Aktivierung:

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(),
                                    });
        };
    }
}

Mittels des Callbacks wird das Event in das Logfile geschrieben.

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

Mithilfe von $self->getUserInfo() wird ermittelt, welcher User den Request ausgelöst hat.
Mithilfe von $imperia->request->imperiaPathInfokönnen Sie, falls weitere Parameter vorhanden sind, ermitteln, ob es sich dabei um eine Löschung, ein Speichervorgang oder einen Patch gehandelt hat.
Beispiel: Ein User wurde gelöscht
```
my ($command, $id) = $imperia->request->imperiaPathInfo;

if($command eq 'delete' && $id) { 
    do something ...
}
```
Um auf einen bestimmten Controller reagieren zu können, muss dieser in getRegistered Controller angegeben werden.

Beispiel: Hermes-Aktivierung soll geloggt werden:
```
sub getRegisteredController {
    my ($self) = @_;

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

Event-Plug-in#

Die Event-Plug-ins liegen unter site/modules/core/Dynamic/Router.

Folgende Informationen sollen im Plug-in enthalten sein:

Package-Pfad angeben package Dynamic::Router::YourEventPlugin;
Ihr Plug-in sollte von der Klasse Imperia::Router::Plugin abgeleitet werden use base qw(Imperia::Router::Plugin);
Die Controller auf welche das Plug-in reagieren kann, müssen zurückgegeben werden in getRegisteredController.

Beispiel: Hermes-Aktivierung soll geloggt werden

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

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

Weitere Methode filter

Jeder Request an einen der oberen angegebenen Controllern wird der Methode filter übergeben. Hier kann dann zum Beispiel entschieden werden, welche Requests auf einen Controller geloggt werden sollen.

Beispiel: Aktivierung des 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(),
                                    });
                }
            }
        }

Nach dem Request

In der Variable $imperia->payload->{imperia}{__callback} können Sie den Code hinterlegen der nach der Abarbeitung des Requests ausgeführt werden soll. In oberem Beispiel wird das Event in die Logdatei geschrieben. Hier füllen Sie die Variablen (z. B. Message) mit den entsprechenden Werten.

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

Mithilfe von $self->getUserInfo() wird ermittelt, welcher User den Request ausgelöst hat.
Falls weitere Parameter vorhanden, können Sie mithilfe der Variable $imperia->request->imperiaPathInfo ermitteln, ob es sich dabei um eine Löschung, eine Speicherung oder einen Patch gehandelt hat.

Beispiel: Ein User wurde gelöscht

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

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

Logdatei (LEEF-Datei)#

Je nachdem welche Felder konfiguriert sind, kann die LEEF-Datei bestimmte Informationen ausspielen. Diese Informationen finden Sie in der Tabelle 2 des IBM Supports:

Table 2. LEEF format despriptions.

Hinweis

Felder, die nicht zutreffen, bleiben leer, z.B. "file= ".

Für LEEF-Ereignisse muss die Zeichencodierung UTF-8 verwendet werden.

Konfiguration#

Die Konfigurationsdatei liegt als Sample unter site/config/leef.conf.sample und kann als Vorlage für die eigene Config genutzt werden. Wenn Sie den LEEF-Logger benutzen, müssen Sie eine angepasste Konfiguration verwenden.

Sie dient zur Konfiguration der Felder, die dort unter <base> liegen und deren Werte aus dem Plug-in gezogen werden. Auflistung möglicher Felder finden Sie unter Beispielkonfiguration im Beispiel 2.

Zudem sind die Header-Daten, die in der LEEF-Datei am Anfang ausgegeben werden, ebenfalls dort festgelegt.

Unter logfilename lässt sich einstellen wo das leef.log gespeichert werden soll.

Damit im Syslog-Header die IPv4-Adresse des Host-Systems erscheint, können Sie diese in der Konfigurationsdatei unter header_systemIP eintragen.

Beispiel 1:

header_systemIP = 127.0.0.1

Unter header_format tragen Sie das entsprechende Leef-Format ein, welches Sie nutzen.

Beispiel 2:

header_format = LEEF:1.0

Eine Beispielkonfiguration könnte wie folgt aussehen:

    '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|10.3
        env = E
        cat = 
        usrName = 
        usrName2 = 
        file = 
        msg = 
        src = 
        dst = 
        srcPort = 
        dstPort = 
        sev = 
        par1 = 
        par2 = 
        role = 
        grpName = 
        role2 = 
        grpName2 = 
    </base>'

Die Felder mit dem Präfix header_bilden dabei den Syslog- und den LEEF-Header. Die Felder ohne dem Präfix bilden die vordefinierten oder kundenspezifischen Event-Attribute.