Skip navigation
All Places > Products > RSA NetWitness Platform > Blog > 2019 > July

G Suite (formerly known as Google Business Suite or Google Apps for Business) is now supported for log collection using the RSA NetWitness Platform.  Collection is achieved via the G Suite Reports API (v1) and is enabled in RSA NetWitness via the plugin framework.



The G Suite API schema provides several types of events which can be monitored.  Below is the list of event types currently supported by this plugin:


  • access_transparency – The G Suite Access Transparency activity reports return information about different types of Access Transparency activity events.
  • admin – The Admin console application's activity reports return account information about different types of administrator activity events.
  • calendar – The G Suite Calendar application's activity reports return information about various Calendar activity events.
  • drive – The Google Drive application's activity reports return information about various Google Drive activity events. The Drive activity report is only available for G Suite Business customers.
  • groups – The Google Groups application's activity reports return information about various Groups activity events.
  • groups_enterprise – The Enterprise Groups activity reports return information about various Enterprise group activity events.
  • login – The G Suite Login application's activity reports return account information about different types of Login activity events.
  • mobile – The G Suite Mobile Audit activity report return information about different types of Mobile Audit activity events.
  • rules – The G Suite Rules activity report return information about different types of Rules activity events.
  • token – The G Suite Token application's activity reports return account information about different types of Token activity events.
  • user_accounts – The G Suite User Accounts application's activity reports return account information about different types of User Accounts activity events.


Suggested Use Cases


G Suite Admin Report:


  1. Top 5 Admin Actions: Depicts the top 5 actions by Admin
  2. Admin activity: Activities performed by admins
  3. App Token Actions: Displays details on app token actions in a pie chart
  4. Users Created and Deleted: Displays users created and deleted as a table chart including details on the user’s email, admin action, and admin email.
  5. Groups - Users Added or Removed: Displays information on Groups, with users added or removed as a table chart including details on the user email, admin action, group email, and admin email.


G Suite Activity Report:


  1. Activity by IP Address: Shows a table of actions w.r.t IPs
  2. Login State Count: A pie chart that depicts the login states by count
  3. Logins from Multiple IPs: Shows logins from multiple IP addresses by user on a pie chart
  4. Most Active IPs: Shows a table with the most active IP addresses based on the number of events performed by that IP address
  5. Top 10 Apps by Count: Shows the top ten apps by count on a column graph
  6. Login Failures by User: Shows the login failures by user on a pie chart


Downloads and Documentation


Configuration Guide: Google G Suite 
Collector Package on RSA Live: Google Business Suite Log Collector Configuration
Parser on RSA Live: CEF (device.type='gsuite')


Sending a notification based on a critical or time-sensitive event seen in your environment is table stakes functionality for any detection platform. Alerting someone in a timely manner is important, but building a custom e-mail that includes relevant, concise information that an analyst can use to determine the appropriate response is just as important. As they work to juggle their daily priorities, they need to know whether an alert requires immediate attention or whether it's something they can filter as a false positive as time permits.


The RSA NetWitness Platform uses Apache FreeMarker template engine to build its notifications, be they e-mail, syslog, or SNMP. For the purposes of this post, I'm going to focus on e-mail notifications as the concepts apply to all notifications, and e-mail is the most complex of the options.


Available Data

The first step is finding out what information you can include in your notification. All of that data can be seen in the Raw Alert section of an Alert in the Respond UI. That Raw Alert is formatted in JSON, and anything in there can be placed into a notification. To find that Raw Alert data, you can go to one of two places.


Location #1:


Location #2:


Example #1: Basic Email

Let's start with a basic example. I want to send an e-mail that includes the name, severity, and time of the Alert, as well as a link to the raw event (network or log) that generated the alert. Here is a snippet of the data from my Raw Alert (the full alert, with addresses changed to protect the innocent, is attached as raw_alert.json):


Under Admin --> System --> Global Notifications, on the Template tab, I add a new template. Give it a name, choose the template type (we're going to select Event Stream Analysis for these), and then paste in the below code (also under example_1.html):


Assuming a severity of 9, that gives an e-mail formatted like this (using Gmail):


Rows 1 - 20 give us a color-coded banner which highlights the severity of the incident. In rows 3 - 6, you can see that we're making a logical check for the severity to determine the background color of the banner. Row 22 (we'll come back to row 21) prints the rule name. Row 23 gives us the time and includes the field, the input format, and the output format. You can even take epoch time and adjust it for your local time zone, but that's another post. Row 25 builds a hyperlink to the raw event that generated the Alert. Keep in mind that by default, notifications will separate large numbers with commas, which is why row 21 is necessary. Without row 21, the notification link (which I highlighted in the e-mail screenshot) would include commas in the sessionid within the URL, which would obviously not work when clicked. Also, you will need to update two portions of the URL specific to your environment:


The [URL_or_IP] is self-explanatory. The [Device_ID] is different for every environment and for every service. If you login to the RSA NetWitness Platform and navigate to the Investigate --> Navigate page and load values, the Device ID will be in the URL string in your browser, and it will correspond to the data source you've selected. In this example, my Broker has a Device ID of 6.


Above, we used https://[URL_or_IP]/investigation/[Device_ID]/reconstruction/[Session_ID]/AUTO. This loads the "Default Session View" that each individual user defined in their Profile --> Preferences --> Investigation settings, which by default is "Best Reconstruction" view for network sessions and the "Raw Log" view for log events. Should you prefer to jump directly to other views, you can use these formats:

  • Meta View: https://[URL_or_IP]/investigation/[Device_ID]/reconstruction/[Session_ID]/DETAILS
  • Text View: https://[URL_or_IP]/investigation/[Device_ID]/reconstruction/[Session_ID]/TEXT
  • Hex View: https://[URL_or_IP]/investigation/[Device_ID]/reconstruction/[Session_ID]/HEX
  • Packets View: https://[URL_or_IP]/investigation/[Device_ID]/reconstruction/[Session_ID]/PACKETS
  • Web View: https://[URL_or_IP]/investigation/[Device_ID]/reconstruction/[Session_ID]/WEB
  • Files View: https://[URL_or_IP]/investigation/[Device_ID]/reconstruction/[Session_ID]/FILES


Great! Now we have a notification.


Example #2: Multiple Values

But what if we have an array of values like analysis_service here:


In order to print those multiple values out, we need do some formatting with a FreeMarker macro. I'm pasting the following onto the bottom of my notification:


Lines 1 - 11 iterate through any meta value that has more than one value and separate them with a comma. Lines 13 - 22 print out Service Analysis with a comma-separated list of values. First, there is a logical test to see if there are any events in the first place. This was taken from the Default SMTP Template (Admin --> System --> Global Notifications --> Templates tab), and can be used to print out every meta key and all of their values. In my case, I altered it (or, well, Josh Randall did and I stole borrowed it) to only apply to Service Analysis by adding a logical test (lines 16 and 19) and then only printing out that one meta key. Here is what that looks like:



If you would like to print out more than one key, you can add elseif statements like this:


Testing Your Syntax

So what if you want to use some FreeMarker concepts, but you want to see if they'll work before putting them into the RSA NetWitness Platform? Luckily, there is a tester put out by Apache here -


In order to use it on your data, just copy that Raw Alert section from an Alert and paste it into the Data model box shown above. Then paste your FreeMarker code into the Template box and click Evaluate. Keep this in mind: this will not work the same as an RSA NetWitness Platform notification would. If I took the Raw Alert I used for my examples above along with the template I was using, I would not see the output I actually get from the RSA NetWitness Platform. This should ONLY be used to test some basic syntax concepts. For example, printing out UNIX Epoch Time in various formats, adjusted for different time zones, is something this helped me do.



These concepts - along with some basic HTML formatting - give you the tools to build just about any notification you would want. I also recommend taking a peek at the Default SMTP Template I referenced above to use as a starting point for more advanced formatting. If you do some other interesting things or need help getting a notification to work, please post that in the comments below.

One of the most powerful features to make its way into RSA NetWitness Platform version 11.3 is also one of the most subtle in the interface.  11.3 now saves analysts one more step during incident response by integrating rich UEBA, Endpoint, Log, and Full Packet reconstruction directly into the incident panel.  This view is essentially the same as if you were looking at events directly in the Event Analysis part of the UI, or the Users (UEBA) part of the UI, just consolidated into the incident panel.  Prior to this improvement,the only way to view the raw event details was to open the event and click on "Investigate Original Event", pivoting into a new query window.  This option may still be appropriate for some, and still exists, but for those needing the fastest route possible to validating detection and event details, this feature is for you.


To use the new feature, for any individual event of interest that has been aggregated or added into an incident you'll see a small hyperlink attached to each event on the left hand side, labeled with one of: "Network", "Endpoint", "Log", "User Entity Behavior Analytics".  These labels correspond to the source of the event, and upon click will slide in the appropriate reconstruction view.


User Entity and Behavior Analytics (UEBA) view:

Network packet reconstruction view:

Endpoint reconstruction view:

Log reconstruction view:


Happy responding!

Starting in version 11.3, the RSA NetWitness Platform introduced the ability to analyze endpoint data captured by the RSA NetWitness Endpoint Agent (both the free "Insights" version and the full version). For more information on what RSA NetWitness Endpoint is all about, please start with the RSA NetWitness Endpoint Quick Start Guide for 11.3.


One of the helpful new features of the endpoint agent is the ability to not only focus the analyst on the "Hosts" context of their environment, but also the ability to gain full visibility into process behaviors and relationships whenever suspicious behaviors have been detected by the RSA NetWitness platform, or when investigating alerts from others.


The various pivot points bring an analyst into Process Analysis in the context of a specific process, including it's parent and child process(es) and based on the current analysis timeline which is adjustable if needed.


Example Process Analysis view, drilling into all related events recorded by the NW Endpoint Agent


Example Process Analysis view, focused on process properties (powershell.exe) collected by the NW Endpoint Agent


The feature is simple to use when RSA NetWitness Endpoint agent data exists, and is accessible from a number of locations in the UI depending on where the analyst is in their workflow:


Investigate > Hosts > Details (if endpoint alerts exist):

Investigate > Hosts > Processes (regardless of alert/risk score): 


Investigate > Event Analysis:


Respond > Incident > Event List (card must be expanded):


Respond > Incident > Embedded Event Analysis (reconstruction view):


Happy Hunting!

Unfortunately sometimes sensitive data can find its way where it is not wanted. It should not, but it happens. Perhaps your IT Person decided connecting the high side network to the low side was a good idea. Maybe someone accidentally uploaded the wrong PCAP (packet capture) to the system. However it happened, there are options to remove that data. If a large amount of data needs to be purged, probably want to start with the storage component (e.g. SAN) to see what capabilities are available. In terms of RSA NetWitness Platform software, one option is to utilize the wipe utility that allows the administrator to strategically overwrite events.


  1. The first step is to find the data in question. This can be done via a query either in the RSA NetWitness Investigate user interface, the REST API interface, or the NwConsole. If use the first option will require additional steps to clear user interface cache on the admin server. This is an example of an event found using the Investigate user interface. The PCAP used in this example has one event and was tagged by name during import to make it easier to query.

  2. After you execute the query make note of the session ID (sid) and remote ID (rid) that can be seen here using a custom column group. They are both in the above view as well, but have to scroll down the list of meta to find the remote id. 

  3. Starting with the concentrator, use the wipe command against those session IDs to overwrite them with a pattern.
    • There are multiple options to the wipe command.
      • session - <uint64> The session id whose packets will be wiped
      • payloadOnly - <bool, optional> If true (default), will only overwrite the packet payload
      • pattern - <string, optional> The pattern to use, by default it uses all zeros
      • metaList - <string, optional> Comma separated list of meta to wipe, default (empty) is all meta
      • source - <string, optional, {enum-any:m|p}> The types of data to wipe, meta and/or packets, default is just packets
    • Note that if you use a string as your pattern it will not overwrite any meta values that are not a string type. Therefore best to keep the pattern as a numerical value.
    • Initially go to the concentrator that was found to have those session IDs (sids) and use the wipe command to overwrite the session meta data on disk.

  4. Rinse and repeat this on the upstream service (e.g. decoder, log decoder) in the path of the query. This time use the remote session IDs (rids) to overwrite the raw sessions on disk.

  5. To ensure that the indexed meta values that were stored on the Concentrator are removed, rebuild the index. This can take a long time but is necessary because the wipe command does not remove any data from the Concentrator index. Refer to the Core Database Tuning Guide for instructions.
  6. Now that you have overwritten the data on the decoder, where it was ingested, and the concentrator, where meta related to it was created, you're done right? Well it depends on how you discovered the data in the first place. If you know for sure no one found the data by way of the RSA NetWitness Platform user interface you should be done. If the user interface was used or you just want to be on the safe side continue to the next step. Otherwise might still see the raw event data being rendered from cache like below.

    • If the Investigate > Event Analysis was used to find the data the cache for the event reconstruction should be cleared by restarting the Investigate service.

    • If the Investigate > Events was used to find the data the event reconstruction cache should be cleared by removing the contents of the service folders on the admin server as shown below.

    • The cache for the concentrator and the decoder can also be cleared by executing the delCache command in Admin > Services > sdk > properties for each as shown below.

    • After clearing the cache attempting to view the same session that was wiped you will see the event is unavailable for viewing.


To gain further knowledge on protecting the data stored within your RSA NetWitness system take a look at the Data Privacy Management Guide.

Filter Blog

By date: By tag: