Audit Trail
  • Updated on 06 Mar 2020
  • 5 minutes to read
  • Print
  • Share
  • Dark
    Light

Audit Trail

  • Print
  • Share
  • Dark
    Light

Early Adopter feature
If you would like to learn more about this feature or want to request early-access, please get in touch with your Mambu Customer Success Manager to discuss your requirements.
Pre-requisites
In order to make use of this feature you must have enabled and set up API consumers

Audit trail - Standalone Capability

The purpose of the Audit Trail project is to get a 360-degree view of all user activities that have been performed in the Mambu system. These activities are of two types: User Interface and API calls and offer a great way to understand what the users are doing and how they are using the Mambu application.

Collecting data from the standpoint of a user identity or login is a great way to correlate all kinds of information so that auditors will be able to retrieve the necessary information in a timely and efficient manner to investigate a potential fraud or other specific action (e.g who initiated certain transaction or journal entry).

Audit records are grouped per tenant and provide information about the action that has been performed, the actual user performing the operation, the resources modified by the operation and the date and time of the operation. These records are also captured as soon as they are generated by the user’s journey or API calls and sent to another system that allows investigators to easily access and interact with the critical data involved via a secured endpoint.

Current features

The current implementation allows an auditor to perform the following activities:

  • Track what has been done the Mambu application, by whom and when it was done.
  • Choose who to audit and what type of information to audit.
  • View in real-time what Mambu application users are doing.
  • Prevent users (or others, such as intruders) from inappropriate actions based on the events generated by their journey.
  • Investigate suspicious activity. For example, if a user is generating a big transaction, then an administrator might decide to audit his latest actions in a given range interval.
  • Detect actions performed by an unauthorized user. For example, an unauthorized user could change or delete data, or a user has more privileges than expected, which can lead to reassessing user authorizations
  • Monitor and gather data about specific activities. For example, the auditor can gather information about which deposits have been created by a specific user.
  • Address auditing requirements for compliance.

Events interceptor

There are currently two types of intercepted audit events:

  • UI Events:

    • those events generated by user's actions. A handler interceptor is used to capture all GWT actions
    • authentication events. An HTTP filter is used for intercepting this kind of event.
  • API Events:

    • covers all the API calls regardless of the API version. A HTTP filter is used for intercepting this kind of event.

All in all, this kind of records will let the auditor build a nuanced view of individual user behavior and activity.

Usage

The audit events can be accessed via a secure public API, which offers a fine-grained auditing search criteria, so that an auditor will be able to perform searches at a granular level and also narrow the search for information.

The API endpoint is secured via API Key, stored in another system and the key will be generated through Mambu UI.

The filters are provided via query parameters using LHS brackets with an operator.

Request example:

GET
<mambu_domain>/api/v1/events?from=0&size=10&event_source[eq]=API&request_payload[contains]=amount

Response example:

{
    "events": [
        {
            "response_code": 401,
            "occured_at": "2018-08-30T13:35:05.023Z",
            "resource": "cards",
            "event_source": "API",
            "client_ip": "127.0.0.1",
            "request_method": "POST",
            "request_payload": "{\"externalReferenceId\":\"1234\",\"amount\":10,\"currencyCode\":\"EUR\"}",
            "resource_fragment": "/api/cards/rtyrtyrtyrty/authorizationholds/yrtyrtyrty:decrease",
            "request_uri": "/api/cards/rtyrtyrtyrty/authorizationholds/yrtyrtyrty:decrease",
            "user_agent": "userAgentInfo,
            "username": "demo"
        }
    ],
    "from": 0,
    "size": 10,
    "totalItemsCount": 1
}

Endpoint description

Operator Description Example
eq Equals - exact match, applies to any type of fields username[eq]=demo@mambu.com
ne Not equals, applies to any type of fields username[ne]=demo@mambu.com
gt Greater than, applies to numeric or date fields occured_at[gt]=2018-05-01
gte Greater than or equal, applies to numeric or date fields occured_at[gte]=2018-05-01
lt Less than, applies to numeric or date fields occured_at[lt]=2018-05-01
lte Less than or equal, applies to numeric or date fields occured_at[lte]=2018-05-01
startsWith Starts with, applies to string fields username[startsWith]=demo
in Element in list (exact match), applies to any type of fields username[in]=user1@mambu.com,user2@mambu.com
contains Will search for all the provided elements in the specified field. Each element (delimited by ‘,’) can consist of multiple terms - but in order for the event document to be matched, the terms must appear in the same order (and not be separated by any additional words) in the event field value. The order of the elements is not relevant. Applies to string fields. request_payload[contains]="provisionedThroughFederation":true, "detailsLevel":"BASIC"
Event fields Description Supported operators
event_source The events that are supposed to be audited fall within the following categories: API, UI eq, ne, in
request_uri Part of the request's URL from the protocol name up to the query string in the first line of the HTTP request eq, ne, startsWith, in, contains
request_method HTTP request method (GET, POST, PUT, etc) eq, ne, in
request_payload The raw request data with striped sensitive information (might be empty) eq, ne, startsWith, in, contains
user_agent The value of HTTP user agent header eq, ne, startsWith, in, contains
resource For API is obtained from parsing the URL. e.g for /api/clients" the resulting value is "clients"
For UI this is obtained from parsing the URL hash. e.g for "#admin.tab=admin_reports.report_type=CLIENT" the resulting value is "admin_reports"
eq, ne, startsWith, in, contains
resource_fragment For API this holds the request URI
For UI this holds the raw URL hash
eq, ne, startsWith, in, contains
username The currently logged in user (might be empty) eq, ne, startsWith, in, contains
client_ip IP address from http request or X_FORWARDED_FOR header if present eq, ne, startsWith, in
response_code HTTP response code eq, ne, in, gt, gte, lt, lte
occured_at The date the event has been generated (when creating queries on this field the provided values must be in ISO8601 standard) eq, ne, in, gt, gte, lt, lte
response_payload The raw response payload eq, ne, startsWith, in, contains

Ask the Mambu Community

If you have a question about how anything works or have come across something you haven't seen explained here, get in touch with our community of fellow users and Mambuvians where someone will lend a hand.

Ask a question about the Audit Trail

* If you don't already have an account you will be prompted to create one when you first visit the site.

Was this article helpful?