Zum Hauptinhalt springen

Live Security Monitoring

Die Zielgruppe von diesem Artikel sind Personen die verantwortlich für den Betrieb der Software sind. Er beschreibt alle möglichen Security Event Typen die im Log vorkommen können und wie man diese Security Events beobachten kann, um in dem laufenden BOC Produkt ein automatisches Erkennen von fragwürdigen und bösartigen Aktivitäten zu erkennen.

Laut OWASP Top 10 ist es essentiell zu erkennen ob und wann ein Angriff auf die Applikation stattfindet. Eine bewährte Methode das umzusetzen beinhaltet folgende Schritte:

  • Beobachten der Security Logs
  • Die Log Einträge nach Security Events zu scannen
  • Ein automatisches Überprüfen ob eine bestimmte Kombination von Events einen Security Alarm auslösen soll
  • Automatisch auf Security Alarme reagieren (zB. eine Benachrichtigung auslösen)

Security Logs Beobachten

Die Security Logs befinden sich innerhalb des Tomcat Log Verzeichnis. Der Name eines Security Logs entrspricht folgendem Muster: [BOC PRODUCT NAME]_Security.log Es gibt eine Vielzahl von unterschiedlichen Third Party Tools die es einem ermöglichen Log Dateien Live zu beobachten. Eine übliche und weitverbreitete Methode ist die Verwendung und Kombination von Elasticsearch, Logstash, und Kibana.

Nach Neuen Security Events Scannen

Sobald man Log Informationen Live verarbeiten kann, ist der nächste Schritt diese Log Einträge nach Security Events zu scannen.

Die folgende Liste beschreibt alle Security Event Typen die in der Applikation vorkommen können: Security Event Types

Jeder Security Event Typ hat eine eindeutige ID und eine technische Beschreibung (auf Englisch).

Als nächstes betrachten wir das Pattern eines Security Log Eintrags:

%d{ISO8601} %X{sec-severity} [%t] [SECURITY] [C\=%X{sec-category}] [IP\=%X{sec-sourceip}] [UA\=%X{sec-useragent}] %m%n

Die wichtigsten Eigenschaften sind:

  • %d{ISO8601}: Der Zeitstempel des Log Eintrags
  • %X{sec-severity}: Wie schwerwiegend der einzelne Event ist
  • [C\=%X{sec-category}]: Die ID des Security Event Typs
  • [IP\=%X{sec-sourceip}]: Der Hash Wert der IP Adresse
  • [UA\=%X{sec-useragent}]: Informationen zum User Agent
  • %m%n: Zusätzliche Informationen

Ein Beispiel diesbezüglich:

2019-03-19 11:24:07,997 INFO [http-nio-8080-exec-5] [SECURITY] [C=ADODEBUG3] [IP=1719016235] [UA=Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.12] [S] [A82CE5B4E253B5443AFA77FCB1CC5909:10172] Changed session debug mode to: true

Triggering a Security Alert

Nicht jedes Security Event benötigt ein Eingreifen. Es kann auch sein, dass ein Security Event in einer bestimmten Frequenz innerhalb eines Zeitrahmens auftreten muss, dass ein Security Alert ausgelöst werden soll.

Die Datei Security Alert Pattern beschreibt Muster von Vorkommen von Security Event Typen die einen Security Alert auslösen sollen. Die Information ist im JSON Format geschrieben, dass eine automatische Bearbeitung ermöglicht. Das JSON beinhaltet eine Versions Information und als Hauptbestandteil die Liste der Detection Points.

Hier ist ein Beispiel eines Detection Points:

{
"id": "DP004",
"description": "Attack on authorization: An attacker tried to trigger admin functionality although he did not have the right to do so.",
"attackType": [
"Elevation of Privileges Attempt"
],
"trigger": {
"type": "SecurityLoggerEventTypeTrigger",
"eventID": "ADOADMIN1",
"threshold": {
"once": true
}
},
"actions": [
{
"type": "notificationAlert"
}
]
}

Die Struktur eines Detection Points hat folgende Eigenschaften:

  • id: Die eindeutige ID des Detection Points.
  • description: Eine kurze Beschreibung was die Ursache für dieses Log Pattern sein könnte.
  • attackType: Eine Kategorisierung des Typs des stattfindeten Angriffsversuches
  • trigger: Die Beschreibung des Auslösers dieses Detection Points.
    • type: Welcher Alarmmechanismus verantwortlich ist. In diesem Fall ist es der SecurityLoggerEventTypeTrigger.
    • eventID: Die ID des Security Event Typs nach der Security Event Types Liste.
    • threshold: Beschreibt wie oft der Event innerhalb eines Zeitrahmens auftreten muss, bevor ein Alarm ausgelöst wird.
  • actions: Eine Liste von Aktionen die automatisch ausgelöst werden sollen wenn der Alarm eintritt.

Diese Information ermöglicht es das bevorzugte Log Monitoring Tool zu konfigurieren, sodass man einen Alarm erkennt und automatisch darauf reagieren kann.

Für den Fall, dass eine solches Live Monitoring für Security Alarme erwünscht ist, aber man sich nicht den Aufwand der Konfiguration und des Betriebs ersparen möchte, dann empfehlen wir die Verwendung unserer Cloud basierten Lösungen für die BOC das Live Monitoring übernimmt.