Overview
If you are looking at retention requirements for compliance, making decisions about the architecture, or to retain a decent investigation history, NetWitness retention is always at the top of these discussions. As we all find out over time, retention is something that needs to be monitored for trends so informed decisions can be made to meet the corporate or regulatory retention requirements. This article will shed some light on retention in the NetWitness Platform Systems and demonstrate how to view the retention numbers as a “stack”. Scroll to the bottom to download the retention script related to this article.
Persistence
There are basically two levels of persistence in the NetWitness Platform:
- Permanent - Final resting place for the data - It is NOT copied to another destination in the platform; i.e Network/Log Decoder raw packets/logs residing on the Network/Log Decoder
- Temporary - Data that is copied (via aggregation) from this location to another device, i.e. The Concentrator consuming meta and sessions data from a Network/Log Decoder. The meta and session data is considered temporary as only needs to reside on the Network/Log Decoder long enough to be consumed by the aggregating Concentrator.
Database Types
Below are the database types and the index used by the NetWitness Platform
- PacketDB – Raw captured log/network data
Present on Log/Network Decoders and Archivers - MetaDB – Meta data generated from Log/Network Decoder parsing and processing (App Rules/Feeds)
Present on Log/Network Decoders, Concentrators and Archivers - SessionDB – Data that links the meta data and packet data together into sessions
Present on Log/Network Decoders, Concentrators and Archivers - Index – Not really a database, but provides a method to lookup sessions using meta key values or session ID's.
NetWitness Systems
Let's take a look at how the database types, persistence, and the retention requirements relate to the individual NetWitness Systems.
Log/Network Decoder
- PacketDB
- Permanent resting place (unless Log Archiver is deployed for Log Decoder)
- Meet Your Requirement Retention Days
- Permanent resting place (unless Log Archiver is deployed for Log Decoder)
- MetaDB
- Temporary resting place
- Typically like to see ~30 Days Retention
- Temporary resting place
- SessionDB
- Temporary resting place
- Typically like to see ~30 Days Retention
- Temporary resting place
Concentrator
- MetaDB
- Permanent Resting Place
- Meet Your Requirement Retention Days
- Permanent Resting Place
- SessionDB
- Permanent Resting Place
- Meet Your Requirement Retention Days
- Permanent Resting Place
- Index
- Permanent Resting Place
- Meet Your Requirement Retention Days
- Permanent Resting Place
Log Archiver
- PacketDB
- Permanent Resting Place
- Meet Your Requirement Retention Days
- Permanent Resting Place
- MetaDB
- Permanent Resting Place
- Meet Your Requirement Retention Days
- Permanent Resting Place
- SessionDB
- Permanent Resting Place
- Meet Your Requirement Retention Days
- Permanent Resting Place
- Index
- Permanent Resting Place
- Meet Your Requirement Retention Days
- Permanent Resting Place
Log Hybrid Retention
- PacketDB
- Permanent Resting Place
- Meet Your Requirement Retention Days
- Permanent Resting Place
- MetaDB
- Permanent Resting Place
- Meet Your Requirement Retention Days
- Permanent Resting Place
- SessionDB
- Permanent Resting Place
- Meet Your Requirement Retention Days
- Permanent Resting Place
- Index
- Permanent Resting Place
- Meet Your Requirement Retention Days
- Permanent Resting Place
Interpreting The Numbers
Viewing The "Stack"
When examining retention it is best to evaluate the systems as a "stack". This will assist in viewing the relationship between the capture devices (Network/Log Decoders) and the upstream consumers (Concentrators) of the data in relation to the corporate goal or regulatory requirement. The image below shows the NetWitness "stacks" in this particular sample architecture. Each individual stack is separated by the "----------", so we can see that there are 15 stacks, two of which are archivers.
Determine The Retention
Determine if your goals or requirements are met by viewing the "Permanent" retention numbers. *Note the Archiver permanent numbers are relative to a "Collection" name, there will always be a "default" collection. If there were other collections, the row for each collection would be the "Permanent" retention numbers.
The Retention Script
Attached is the retention script used to provide the outputs shown above.
The script provides output to file in two text formats and outputs to local and/or syslog target:
- Table for console viewing (text format)
- CSV for use in other programs
- Syslog (CEF Format), it can send to a syslog target (unencrypted only - Logger limitation)
- It writes the output to /var/log/messages (CEF Format)
Requirements
In order for the script file to function as designed, you will need the following prerequisites:
- Install the NwBackup script, particularly the following scripts:
- Run get-all-systems11.sh
- Run ssh-propagate11.sh
Installation
- Download the retention script at the end of this article
- SSH to the console of the NetwWitness Server (Node Zero)
- Login as the "root" user
- Create the /root/scripts/admin
mkdir /root/scripts
mkdir /root/scripts/admin - Create the retention directories to store the output files (these are the defaults).
mkdir /root/retention
mkdir /root/retention/table
mkdir /root/retention/csv - Using WinSCP or other client to copy the script to the NetWitness Server (Node Zero) /root/scripts/admin directory
- Make the script file executable
chmod +x /root/scripts/admin/netwitness_retention_csv.sh - Edit the script file variable values to match your output directories, syslog server, and number of history days to keep for the CSV and table text files.
Manual Execution
- SSH to the console of the NetwWitness Server (Node Zero)
- Login as the "root" user
- After you have completed the Installation Steps, type the following command
/root/scripts/admin/netwitness_retention_csv.sh - You will see ouput to the console similar to below
Crontab Scheduling Instructions
- SSH to NetWitness Server (Node-zero)
- Login as "root"
- Edit crontab
crontab -e - Add to crontab to execute once every 24 hours at 11pm UTC
Press the following key
Insert
add the following text at the top or the bottom of the file
## Retention Script ##
0 23 * * * /root/scripts/admin/netwitness_retention_csv.sh
Press
ESC
Type the following keys
:wq
Press
ENTER
Additional Notes
Since this data is now passed to the /var/log/messages it can ingested by the Log Decoder and partially parsed. There will be a follow up article on properly parsing it and pulling this data into the Reporting Engine to spot trends. Due to time constraints I was not able to add it to this article.
