Skip to main content
Version: 12.0

Live Security Monitoring

This article is intended for persons who are in charge of operations. It contains a list of security events which may appear in the logs and shows how these can be monitored to automatically detect suspicious or even malicious activities, no matter if they are triggered by legitimate users or unauthorized attackers.

Regarding the OWASP Top 10 it is essential to be able to notice if any such activity is going on and react immediately when an application is under attack. A best practice approach contains the following steps:

  • Monitoring of the Security Logs
  • Scanning new log entries continuously for security events
  • Evaluating if a certain combination of events should trigger an automated alert
  • Automatically reacting to a security alert (e.g. by triggering a notification to the application responsible)

Monitoring Security Logs​

The security logs are found in the Tomcat Log folder where all other logs are stored as well. The naming scheme is: [BOC PRODUCT NAME]_Security.log. There is a wide range of third party tools available to use for live monitoring and processing of log files. A frequently used and well-documented combination of tools is Elasticsearch, Logstash and Kibana (ELK), which is also used for the BOC SaaS offerings.

Scanning for New Security Events​

While scanning the logs for security events, you will encounter the following patterns used in BOC security logs. The list of Security Event Types contains all security event types that may be triggered by the application in the current version.

Each security event type has a unique ID and conforms to the following pattern:

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

The important properties to scan for are:

  • %d{ISO8601}: The timestamp of the log entry
  • %X{sec-severity}: The severity of the event
  • [C\=%X{sec-category}]: The ID of the security event type
  • [IP\=%X{sec-sourceip}]: The hash value of the IP address
  • [UA\=%X{sec-useragent}]: The user agent if available
  • %m%n: An informative message with additional details

Here is an example of what you can expect to find in the log:

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

Evaluating if a Security Alert Should be Triggered​

When evaluating a security event from the log, it is important to take the severity level into account. There are informative security events, which do not require immediate actions, and only if they occur above a certain frequency threshold or in a certain combination will trigger a security alert. Other severity levels will require immediate action either fully automated or by operations personnel.

Automatically triggering a Security Alert​

The file Security Alert Patterns lists patterns of security events that should cause a security alert if found in the logs. The file is in JSON format to make it fully machine-readable while also keeping it readable for human operators. Below the included version information at the top you will find a list of detection points which look like the example below:

{
    "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"
        }
    ]
}

The important properties to scan for are:

  • id: The unique ID of the detection point.
  • description: A short description of one or more possible causes for this log pattern.
  • attackType: A categorization of which class of attack attempts typically triggers this alert
  • trigger: How the security alert of this detection point will be triggered.
    • type: The alert mechanism that caused this trigger, e.g. "SecurityLoggerEventTypeTrigger" in the case of our application
    • eventID: The ID of the security event type according to the Security Event Types list
    • threshold: How often this event needs to occur within a certain time frame to trigger an alert
  • actions: A list of actions to be triggered in case this alert occurred

These provided details regarding security log entries should allow you to configure the monitoring tool of your choice in a way to enable you to react in a reliable and timely fashion to potential attack vectors and thereby minimize the potential for a security breach.

If you want to benefit from professional security monitoring by experts without the need to maintain a team of experts and the required software yourself, we invite you to have a look at the BOC SaaS offerings where continuous automated monitoring is included.