As part of the Investigation module, Malware Analysis allows RSA NetWitness users to investigate network sessions flagged by the Concentrator based on a risk score. Malware Analysis is packets-only.
Event Stream Analysis (ESA) correlates multiple events into a single alert based on a set of defined rules. It differs from the Reporting Engine in that it can correlate multiple sessions rather than just a single session. The ESA draws upon meta from both Log and Packet Concentrators and feeds the alerts to the Incident Management database on the Admin Server. ESA utilizes no additional storage.
Archiver
The Archiver indexes and compresses logs and log meta for long-term storage, providing extra storage because log meta requires so much more storage capacity than packet meta. The Archiver is the source for investigations and Reporting Engine reports. The Archiver utilizes tiered storage, with the highest, default tier storing the log data that is in active use as part of the business process, accessible by the Reporting Engine.
The Archiver storage tiers are defined as follows:
- Hot Tier - As the Archiver’s default mode of storage the Hot Tier stores readily accessible logs for reporting and other tasks. Hot storage is typically on Direct-Access Capacity (DAC) or Storage Area Network (SAN) storage.
- Warm Tier (Optional) - Logs stored in the Warm Tier are older than those in the Hot Tier but are also accessible for reporting and other tasks. Data access is slower than with the Hot Tier. Warm storage is usually Network Attached Storage (NAS).
- Cold Tier (Optional) - Logs in the Cold Tier are offline, so this tier is used for retaining data that is needed for regulatory reasons or other long-term purposes. Data in the Cold Tier is no longer managed by the Archiver and must be restored to the Hot or Warm Tier if access is required.
Data Warehouse (no longer sold by RSA)
The Data Warehouse is used for very long-term storage, allowing reporting that spans date ranges of months or even years. It stores data as Avro files. (Avro is a data serialization framework for Hadoop that stores data in a compact binary format.) For the Data Warehouse the Avro files are generated by the Warehouse Connector and consist of compressed and serialized raw logs, log meta, and packet meta.
One additional way that the Data Warehouse differs from the Archiver is that it has analytical capabilities, while the Archiver is for long-term storage only. Big Data analysis is provided for the Data Warehouse by Pivotal or MapR.
NOTE: RSA no longer sells the Data Warehouse.
Warehouse Connector
The Warehouse Connector can be run as a service on a Log Decoder or as a virtual appliance. It takes aggregated data from Log and Packet Decoders, and compresses and serializes it into AVRO files that ultimately consist of raw logs, log meta, and packet meta.
3.0 Deployments
There are five basic ways to deploy the RSA NetWitness Platform in a business-security environment:
- Incident Detection and Compliance (logs only) – For compliance purposes, the Archiver is used to store logs and log meta. ESA is used for detection.
- Network Security Monitoring and Investigation (packets only) – Utilizes the reports and alerts from the Analytical Server. ESA can also be used for alerting purposes.
- Advanced Analysis (logs and packets) – Provides for research into long-term trends and patterns, including visualization and statistical analysis. Needs ESA and a warehouse for long-term storage.
- Archiving and Advanced Analysis (logs and packets) – Adds the Archiver to the Advanced Analysis deployment.
- As part of a SIEM – NetWitness feeds packets to the SIEM. ESA is used for advanced analytics and alerts.
4.0 Meta Creation
Decoders and Concentrators create meta by the use of parsers, feeds, and application rules.
4.1 Parsers
- Parsers act upon the raw data in Decoders.
- Network parsers identify protocols, file types, and data from network sessions. Together, this information allows the reconstruction of network sessions.
- Log parsers map raw logs to an event taxonomy. For example, syslog information is parsed to obtain the login/logoff usernames.
- Custom parsers are written by customers to apply to a specific purpose needed for their business. For example, a custom network parser might look for specific tokens or the use of particular applications.
4.2 Feeds
Feeds act upon existing meta to enrich it and create additional meta. There are different types of feeds. For example:
- Threat intelligence feeds – subscriptions to RSA First Watch, Spy Eyes, etc.
- Identity feeds – mapping of active directory usernames to actions within the environment.
- Custom feeds – feeds that give context that is meaningful within a particular business unit, facility, etc.
4.3 Application Rules
Application rules dynamically generate new information based on existing meta. They are applied at the single-session level. They not only aid in creating custom alert meta values, but can filter out the traffic that does not add value when analyzing the data.
For example, a “Failed Logon” application rule would detect an activity such as:
activity=logon && ec.outcome=failure && user=”jdoe”
When a rule resolves as a binary positive then it can be used to generate an alert.
Application rules also simplify the task of querying. For example, when looking for failed logins, instead of having to search on the entire string given above, the search could be simply for “Failed Logon”.
4.4 Correlation Rules
In a manner similar to application rules, correlation rules also dynamically generate new information based on existing meta, but do so for multiple sessions over a sliding time window. When a match is found, the service creates a new “super session” that identifies other sessions that match the rule.
Figure 1: A basic RSA NetWitness deployment
on Jun 28, 2018Last modified by RSA Customer Support 