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.
- 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.
![NW 11.3 blog start light theme.png NW 11.3 blog start light theme.png](/t5/image/serverpage/image-id/28676iF8D09F56CBFA983E/image-size/large?v=v2&px=999)
- 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.
![NW 11.3 wipe blog #2 list of sessions.png NW 11.3 wipe blog #2 list of sessions.png](/t5/image/serverpage/image-id/28678i125CC117BE1AD13C/image-size/large?v=v2&px=999)
- 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.
![NW 11.3 wipe blog #3 clearing conc event.png NW 11.3 wipe blog #3 clearing conc event.png](/t5/image/serverpage/image-id/28675iA44D08B46D16669A/image-size/large?v=v2&px=999)
- 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.
![NW 11.3 wipe blog #4 clearing dec event.png NW 11.3 wipe blog #4 clearing dec event.png](/t5/image/serverpage/image-id/28677i71A082351EE1A567/image-size/large?v=v2&px=999)
- 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.
- 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.
![NW 11.3 wipe blog #5 after wipe but pre clearing cache.png NW 11.3 wipe blog #5 after wipe but pre clearing cache.png](/t5/image/serverpage/image-id/28674i4E931378724B0FB4/image-size/large?v=v2&px=999)
- 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.
![NW 11.3 wipe blog #6 investigate service restart.png NW 11.3 wipe blog #6 investigate service restart.png](/t5/image/serverpage/image-id/28679i790F8A5BDD3D4172/image-size/large?v=v2&px=999)
- 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.
![NW 11.3 wipe blog #7 clearing events cache.png NW 11.3 wipe blog #7 clearing events cache.png](/t5/image/serverpage/image-id/28680iC40907F668FB13F3/image-size/large?v=v2&px=999)
- 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.
![NW 11.3 wipe blog #8 clearing conc cache.png NW 11.3 wipe blog #8 clearing conc cache.png](/t5/image/serverpage/image-id/28681i22D0D6B9B4C5F84F/image-size/large?v=v2&px=999)
- After clearing the cache attempting to view the same session that was wiped you will see the event is unavailable for viewing.
![NW 11.3 wipe blog #9 after wipe and clearing cache.png NW 11.3 wipe blog #9 after wipe and clearing cache.png](/t5/image/serverpage/image-id/28682i1D9B8F05A0AA01B6/image-size/large?v=v2&px=999)
To gain further knowledge on protecting the data stored within your RSA NetWitness system take a look at the Data Privacy Management Guide.