Leveraging Splunk to Aggregate Axiomatics Policy Server Log Data

Joffry Ferrater   ·   Thursday, June 8th, 2017

Splunk is a Security Information and Event Management (SIEM) tool that can be used to aggregate and analyze security logs. Axiomatics Policy Server (APS) can be configured to generate audit logs that monitor who logs in to the Axiomatics Services Manager (ASM) and who does what within the ASM.  The Axiomatics Policy Decision Point (PDP) that is a part of the Axiomatics Policy Server (APS) can also be configured to log extensive information about the requests it receives, the attributes retrieved from the connectors, the decisions it makes and the responses that are returned to the calling application, i.e. a Policy Enforcement Point (PEP). We know that’s a lot of terms and acronyms, but if you can bear with us, you’ll find this integration is really interesting. 
Splunk is a tool that can be leveraged to analyze many different kinds of log information and data from many different applications and solutions in the deployed environment. The purpose of this is to get an aggregated view and real-time monitoring of security events within the environment. This would be a very difficult task to achieve by individually reviewing each and every application’s own logged data.
In addition, SIEM tools are capable of handling long term storage of log data. This is something that is often lacking in the applications out-of-the-box and SIEM tools like Splunk can be leveraged to produce reports based on stored logging information.
Another strength of a SIEM tool is to be able to read logs in many different formats and still be able to aggregate and process that data and information centrally in a similar way for all applications.
It is, in principle, possible to integrate the Axiomatics solutions with any SIEM tool in the market. The Axiomatics solutions use a standardized format for its logging and should be readable by almost any SIEM tool. However, in order to speed the process of integration, Axiomatics have created a solution specifically to support Splunk in a more streamlined and easy manner.

Integration with Splunk

ASM can be configured to enable detailed audit logging that monitors changes within the system. This can, for example, log who is logging in to ASM itself, if an Attribute Connector or an Attribute is created or deleted and much more. This information is logged to a file in accordance with the configuration of the application container that ASM runs within.
The Axiomatics PDP has the capability to perform detailed audit logging. When this is enabled the PDP will log each and every authorization request handled by the PDP in an XML format where each row in the log file represents an authorization request.

How to set it up

The Axiomatics integration with Splunk comes as a Splunk Application that provides pre-made definitions of ASM and PDP logging events. This makes it possible for Splunk to easily parse the ASM and PDP log data.
There are 3 main steps to get the integration operational

1. Install the APS application in Splunk
2. Setup and configure the feed of events from ASM and/or PDP to Splunk
3. Run reports

Installing the APS application in Spunk is outlined in the documentation for the APS product package. That will not be covered in detail in this blog post and is only available on the Axiomatics Customer Hub. 
There are several ways to have both the ASM and PDP log data fed to Splunk. One of the most convenient ways is to install and configure a Splunk forwarder. This component will monitor a specific log location and automatically forward the logs to Splunk. Follow the instructions in the Splunk Integration Guide for further details on installation and configuration.
Other configuration options are available to feed data into Splunk. One way is, for example, to manually import files containing the log data information. However the option of using the forwarder is most likely the most automated and real-time approach.

ASM Reports

The ASM reports can provide information about the users logging in to the ASM, attributes defined in the central attribute dictionary, Attribute Connectors configured, etc.
These reports are very useful for auditing the authorization environment as a whole. The reports allow for traceability about who did what changes to the authorization environment and at what point in time.

PDP Reports

There are 2 main parts to the PDP reports.

Statistics for PDP decisions

This is a simple report that will present the statistics around the number of Permit, Deny, Not Applicable and Indeterminate decision results made by the PDP(s), as reported to Splunk. It is presented by default as a bar chart graph. Each bar representing a decision can be clicked to drill down further to get the full details for each and every decision of that type (Permit, Deny, etc.). These details are the same as explained below for PDP events.

PDP events for attribute

This is a report designed to present detailed information on the PDP, even based on searchable information. Attribute- Category, Id, Type and Value all play a part in how this report can be used and what information the report presents and as such requires a bit more configuration before it can be fully utilized. In short, all aspects of the Attribute(s) that is going to be used for the search needs to be set up.
In order to configure this, go to the PDP events for attribute view and click the Edit button in the top right corner and choose Edit Source (see screenshot below).

This will open up an editor form where the source information that is used for populating the drop-down menus used to configure the search can be edited.
The first section will not have to be changed in most cases, as this defines the Attribute Category. The defined Categories are the XACML standard categories so unless there are custom defined Categories used within the environment, the default ones can be used without any change made to the out-of-the-box setup.
For example from the default information described below, “access-subject” is what will show up in the drop-down box and that will correspond to the value “urn:oasis:names:tc:xacml:1.0:subject-category:access-subject” and “action” will correspond to “urn:oasis:names:tc:xacml:3.0:subject-category:action” and so on.

The next section to edit in the source (XML) is the definition of Attribute Ids. This is the most important section to edit as it will be heavily dependant on the Attribute Ids used in the environment.
It is important that the value defined (e.g. com.axiomatics.cars.role below) is the fully qualified Attribute Id as defined and used within the XACML environment and not the short name. This is because the Splunk search that generates the reports will search through the actual PDP event log information and the fully qualified name is used within that log data.

The section defining the Attribute Types needs to correspond to the Attribute Types that are used in the environment and that are defined for the Attribute Ids defined in the previous step. For example, if com.axiomatics.cars.role is a string and com.axiomatics.cars.department is an integer, then the string and integer Attribute Types needs to be defined within this section.

The last section simply defines the input field for what Attribute value should the search be looking for. This is defined as an input text box.

With these changes made, finalize the edits by clicking Save at the bottom. The drop-down lists should now reflect the edits made in the source XML.

Searching PDP Events

Once the above parameters have been configured, it should be possible to search for PDP events based on specific Attribute values.
Start with selecting the Attribute Category of the Attribute that you want to use as the base of the search. Then select the Attribute Id and Type. Note that it is possible to select the wrong combination here as Splunk does not know what Category and Type a given Attribute would be, so this is a manual process to make sure that the various properties of the attributes match up with what is defined in the XACML environment. If this is not defined correctly, the search will most probably result in no results.
When all input parameters are selected appropriately and a search term for the attribute value has a match to that Attribute Value within the PDP event information log, Splunk will generate a list of results as shown below. The high level list shows the Time of the event, the identifier of the PDP that handled the event and what the XACML Decision was.

It is possible to drill down on each event to get the full set of information. Clicking on the line of an event creates a search based on that event and the search criteria is defined in a box at the top of the screen. Splunk will then list events in a list below, based on that specific search criteria. To see the full details of individual events, switch to the Events tab.

For a specific event it is then possible to expand to see all of the information that is available in the detailed log entry for the PDP event by showing all the lines (e.g. Show all 60 lines) for a specific event. These are details such as evaluation time, client source (IP), policy the yielded the response (if available), detailed attribute information and much more.

Conclusion

SIEM tools provide capabilities for real-time analysis of security log and event data generated by applications. The data can be leveraged to generate useful reports for audit purposes. In addition to that, SIEM tools are powerful in generating security alerts based on event correlation that can be done across multiple different applications data.
Axiomatics provides out-of-the-box integration with Splunk using an application add-on to Splunk. Splunk is then configured with a feed of data from Axiomatics ASM and PDP and configured with Attribute details in order to fully leverage the PDP reports that are based on Attribute value searches.
To learn more about Splunk, and other integrations, please visit our Integrations and APIs page.
For more information on our technology and integration partners, please visit our Partners page.