Audits
Running the Grey Matter sidecar alongside a service allows for the auditing of request traffic and security information.
Audits
Key Definition
Audits are a security-relevant event within Grey Matter. An audit event, or simply event, can be either or both of the following:
Change to the security state of the system
Attempted or actual violation of the system access control or accountability security policies
An audit event report includes the following information:
Name of the event
Success or failure of the event
Additional event-specific information that is related to security auditing
The Grey Matter Sidecar emits audit data to a Kafka topic for easy observability.
If Fabric is set up with an Edge, it pulls audit data from the PKI certificate, the IP address of the originating request, etc.
This audit data--also called events or observables--allows for detailed event auditing of ingress and egress traffic, and process resource use.
Grey Matter Configuration
Auditing is configured on a sidecar via the Grey Matter observables filter. The information can be emitted to an Apache Kafka cluster and visualized in a Kibana dashboard or can simply be emitted to stdout in the sidecar logs.
For a step by step to configure and visualize auditing in Grey Matter, see the Audits and Observables guides.
For more info on visualizing audits, see the Audit Proxy Observable Consumer section
What about Splunk?
While the Grey Matter Sidecar does not support direct emission of events into Splunk, you can create or modify a consumer to provide that capability. Learn more.
Indexing
Grey Matter does not index audit events directly into Elasticsearch. Instead, Grey Matter contains a Kafka consumer that reads Kafka observables. This consumer transforms and indexes them to use with Elasticsearch.
Use Kibana to Visualize Observables
Kibana is an open source Elasticsearch plugin that takes observables from Grey Matter and visualizes them in a graphical dashboard.
Kibana simplifies the creation of visualizations to explore, search, view, and interact with audit data stored in Elasticsearch indices. Kibana helps you analyze and visualize individual events and trends such as:
Total requests
Number of requests by individual users
Geographic locations of requests made in Fabric
What individual users are doing
Timing of user requests
What user are looking at
user DNs (Authenticated user names)
Geographic location of IP addresses
Requests per hour by user
Response codes
Paths
Service vs. userDN
Services
Response bodies
User agents
Observable Information
The list information in a Grey Matter observables can be found here.
The following observable information was captured from a user accessing an event through a Sidecar operating within Grey Matter Fabric:
Audit Proxy Observable Consumer (APOC)
The Audit Proxy Observable Consumer (APOC) reads from Kafka and submits the information to Elasticsearch asynchronously for maximum throughput. When deploying with the ELK stack, Logstash operates as the APOC.
APOC's goals include:
Listening to given Kafka topic(s)
Taking every event that is emitted into Kafka
Transforming those events
Submitting them to a given Elasticsearch index
Message Transformation
When a message is transformed by the APOC, event mappings are also added. The message will default to the following HTTP types found below:
The message can also be changed for individual routes by adding the following settings:
During the transformation action_locations are added to the audit event. These consist of an IP address identifier based on the x-forwarded-for in the header of the request.
action_targets is added consisting of {x=forwarded-proto}://{:authority}{x-envoy-original-path}.
Determine Value of Creator
A creator is then added to the auditing payload, and follows these steps to determine its value.
Allow for configuring an override default to that in the environment variable or
settings.yamlor JSON.If there is a request header named
application, use it.See if there is a request header named
service, use it.Extrapolate the name if the request url contains
/apps/{value}/or/services/{value}/ x-envoy-original-path.Hard code a default. For instance, you could use
serviceif none of the previous parameters are set.
In this configuration, the transformation will try to find user information in the request header and set action_initiator to be the userdn from the request. time_audited is also added to the audit information. This is the system time at which the audit transformation is completed by the APOC. Finally, if a GEO_DATABASE is supplied, the transformation will try to find the geographical location of the request based on the last IP address in the x_forwarded_for header field. The full information is added to the audit information as geo_ip, but basic location (lat and long) is added as location.
Questions
Create an account at Grey Matter Support to reach our team.
Last updated
Was this helpful?