Theoretical

RSA NetWitness Logs and Packets®
Foundations
Student Guide
ED-SA-FND-310
Rev P10
© 2017 Dell-EMC Corporation

All Rights Reserved
DO NOT DUPLICATE
DO NOT DUPLICATE
Notice
Trademarks
RSA, the RSA Logo and EMC are either registered trademarks or trademarks of EMC
Corporation in the United States and/or other countries. All other trademarks used
herein are the property of their respective owners. For a list of RSA trademarks, go to
www.emc.com/legal/emc-corporation-trademarks.htm#rsa.
THE INFORMATION IN THIS TRAINING MATERIAL IS PROVIDED "AS IS." EMC

CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND
WITH RESPECT TO THE INFORMATION IN THIS TRAINING MATERIAL, AND
SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE
©2017 Dell-EMC Corporation. All rights reserved.
ED SA FND 310
P10
RSA® Security Analytics Foundations DO NOT DUPLICATE 1

Table of Contents
Course Objectives .............................................................................................. 5

Module 1: RSA® Security Analytics Overview ...................................................... 7
Security Analytics Components and Architecture ............................................... 9
Security Analytics Data ..................................................................................... 16
Security Analytics User Interface ...................................................................... 21
Customizing the Interface ................................................................................. 24
Exercise: Customizing the Interface .................................................................. 26
Module 2: Investigation Basics ......................................................................... 29
Investigation Module Navigation Options ......................................................... 31
Creating Queries ............................................................................................... 38
The Investigation Events View .......................................................................... 43
Customizing Your Displays ................................................................................ 55
The Context Hub ............................................................................................... 65
Exercises: Investigation Basics .......................................................................... 70
Module 3: Refining the Dataset....................................................................... 73
Using Filtering Techniques ................................................................................ 75
Exercises: Reducing the Dataset with Filters ..................................................... 87
Building New Metadata .................................................................................... 88
Feeds .............................................................................................................. 102
Exercises: Enhancing the Data with Feeds and Rules ...................................... 111
Investigating with Refined Data ...................................................................... 112
Exercises: Investigating the Data Set............................................................... 115

Table of Contents, continued
Module 4: Reporting and Alerting ................................................................. 117

Configuring the Reporting Engine and Incident Management ........................ 119
Exercise: View RE Configuration and Configure Incident Management .......... 125
Reports Module .............................................................................................. 126
Exercise: Create Reports ................................................................................. 135
Exercise: Create Reporting Alerts.................................................................... 136
Event Stream Analysis Overview ..................................................................... 137
Configuring ESA .............................................................................................. 144
Exercise: Create an Enrichment Source........................................................... 151
Exercise: Configure Threat Detection.............................................................. 152
Creating ESA Alerts ......................................................................................... 153
Best Practices and Approaches ....................................................................... 163
Exercise: Create and View ESA Alerts .............................................................. 169
Managing Incidents ........................................................................................ 170
Exercise: Manage Incidents............................................................................. 178
Appendix: Additional Information................................................................. 181

The information that traverses networks has grown to a volume that far exceeds any
human capacity to monitor. Nonetheless, organizations need tools and processes to
monitor all their network traffic, in order to defend their assets, prevent malicious
intrusions and destructive attacks, to protect the privacy of legitimate users of the
network, and to demonstrate compliance with applicable information security laws.
RSA Security Analytics is a tool that accomplishes those tasks and meets those goals.
It gathers and analyzes network and log traffic, as a way to alert human operators that
“events of interest” may be occurring on the network. It reduces an impossibly large
task to human size, enabling analysts to understand and manage the traffic that crosses
the networks for which they are responsible.
From a very high level, without referencing any of the components yet, let’s take a
conceptual look at the Security Analytics architecture.
Starting on the left, Security Analytics collects raw data from your network. It then
parses the data, enriches the data, and stores it in variables known as metadata. Data
and metadata can be stored in several ways, depending on how long you need to retain
it and what you intend to do with it. Using such tools as feeds, rules, and alerts, you can
perform analysis on the data and then respond based on what you find.

A packet is an atomic unit of data which, when combined with some number of
additional packets, forms a session between two network devices. Human-level
information is packetized for transmission across the network, and packets are later
reconstructed back into sessions that can be read and understood by human beings.
A session can be characterized as a conversation between two network entities. It
usually has a clearly delineated beginning, middle, and end, and takes place using
agreed upon protocols for the exchange of information. In networking, the protocol
provides us with the key elements that allow us to understand the communication.
In network analysis, these elements are defined within the IP protocol suite, and include
(among many others) the following:
• Source IP address
• Source port
• Destination IP address
• Destination port
• Timestamp
• Volume of data exchanged
The Security Analytics platform performs full content collection, and then automatically
identifies and reconstructs discrete sessions, enabling analysts to quickly interpret and
understand the content and context of network sessions.

At the hardware level, RSA Security Analytics consists of a number of separate devices,
referred to as Hosts.
The core physical hosts include:
• SARE – The Security Analytics software (User Interface), Reporting Engine, Malware
Analysis, IPDB Extractor, and Incident Management are on this host.
• Decoders – Log and Packet decoders are the hosts responsible for data collection,
session construction, meta creation, and short-term storage of session and log data.
• Concentrators – The hosts responsible for indexing and short-term storage of all
metadata in the Netwitness Database (NWDB). The Concentrator can aggregate
multiple Decoders, or be paired with a single decoder in a larger SA implementation.
• Broker – This host is required when distributing queries across multiple Concentrators
and Archivers. It is helpful in enterprise sites with multiple collection points, and can
aggregate concentrators across separate geographical locations.
This slide shows a deployment using both a Packet and Log Decoder. The Log Decoder
passes log meta and data to its dedicated concentrator, while the Packet Decoder does
the same with packet meta and data. The two Concentrators are aggregated at the Broker,
where log and packet meta can be manipulated together for a more robust investigation.
The user interface is on the SA server. It is here that Security Analysts can aggregate and
filter data, issue queries, and define and run detailed forensic reports.
Other offerings for the core hosts include:
• Hybrid – The Hybrid is a combined Decoder/Concentrator platform, for optimizing
branch performance on a single platform and lowering total cost of ownership.

Additional Security Analytics hosts include:
• Storage - Security Analytics has a modular-capacity architecture enabled with direct-
attached storage (DAS) or storage area networks (SANs) to host the NWDB. Additional
storage devices include the Archiver, and the IPDB. These are all separate storage devices
optimized for different purposes.
• Archiver – provides for long-term storage of log-only data and meta, to facilitate compliance
reporting over a period of months or years.
• Event Stream Analysis (ESA) – Identifies patterned or related events, and provides for
complex correlation and event processing in near real-time.
Log Data (both raw and meta) can similarly be passed from the Log Decoder to the Archiver, for
long-term retention and compliance reporting needs.
Concentrators can pass data (log and packet meta) to the ESA host, where it can be passed
through complex rule-sets to generate timely alerts; to the Broker, where data from multiple
Concentrators can be aggregated; or, directly to the SA server, where the Investigation,
Reporting, Malware Analysis, and Incident Management engines reside.

Not every implementation will use every host. Nearly every implementation will make
use of the Core Hosts, however: one or both Decoders, at least one Concentrator,
optionally a Broker, and the SA Server Host. In order to understand Security Analytics,
it is essential to understand the functions that these core hosts fill.
The Decoders are responsible for capturing raw data for analysis. The Packet Decoder
captures raw packets directly off the wire, while the Log Decoder ingests log files from
potentially thousands of hosts on the network. The critical function of both decoders is
not just to collect data, but to parse raw data into metadata. Virtually everything you
do with Security Analytics will involve the manipulation of metadata in some way.
A Decoder parses data into metadata by, e.g., taking a string of bytes from an packet
flow, or a string of characters from a log, and assigning them a variable (meta key)
name, such as “Username” or “Source IP Address”. The parsing of data into metadata
turns an undifferentiated mass of bytes or characters into a database of discrete, named
variables. The resulting database (NWDB) is fully searchable, and can be manipulated
to produce additional metadata, identify suspicious activities including malware, trigger
security alerts, and to run complex reports for both forensic and compliance purposes.
The Concentrator aggregates and indexes metadata fields (meta keys), and presents
them to the Server, where the analyst can perform investigations, run reports, configure
alerts, etc. Metadata “moves” from the Concentrator to the SA host when an analyst
requests it, typically through an investigative query, an alert, or a report.
The diagram above portrays a single concentrator aggregating data from two decoders.
A larger implementation would dedicate a concentrator to each decoder, and aggregate
the concentrators at a Broker. Both architectures are valid, and choosing one depends
primarily on the size of your network.

The Live module is the component of Security Analytics that manages communication
and synchronization between Security Analytics services and a library of Live content
available to RSA Security Analytics customers. RSA Live is a content management
system (CMS) that serves up continually updated threat intelligence and tools, gathered
continuously from the worldwide security community. It provides a view into the
collective intelligence and analytical skills of that global community, to ensure that users
have the widest visibility into current attack vectors.
Live provides a simple interface for browsing, selecting, and deploying content from the
Live CMS to Security Analytics services and software. In addition to managing feeds,
rules, reports, keys, alerts, and other packages from the CMS Library, Live allows users
to deploy custom feeds based on their own business intelligence.
Live gathers the best advanced threat intelligence and content in the global security
community - the ideas, research, ongoing tracking, and analysis - and brings it directly
into the user’s security operations center to definitively identify and classify network
devices and domains associated with botnets, malware, and other malicious exploits.

Reporting Engine data sources are physical storage devices. There are a number of
storage options, as depicted above. Each device is optimized to a particular purpose or
need. As we’ll see, it is often more useful to think of storage for reporting purposes in
their logical or virtual organization as databases, rather than as physical devices.

The Security Analytics databases, as they appear logically to the Reporting Engine, are
shown above.
The Netwitness Database (NWDB) is the repository that will be used most heavily in
this course. It is generally thought of as the data that resides on the Decoders and the
Concentrators that can be queried in both the Investigation and the Report modules. It’s
important to remember, though, that Archiver data also resides in the NWDB, and can
be also queried directly from the Reporting Engine.
The IP Database (IPDB) is the legacy database solution in use by many RSA enVision
customers. It continues to be supported in Security Analytics, in both its network-
attached and host-specific versions. IPDB provides normalized and raw event
messages that can cover significant historical time periods.
An option to continued use of the IPDB for enVision customers is to migrate the data
into the NWDB. RSA Professional Services has offerings to assist with this process.

The above slide compares the SA longer-term storage device (Archiver), and contrasts
it with the Concentrator. Both devices work together to perform different but related
functions.
The Archiver is optimized for reporting against very long-term log (log-only) data, and is
usually used for compliance reporting purposes. As we’ve noted, the Concentrator
aggregates data and meta from both log and packet decoders, to enable queries and
reporting against near real-time data. The Concentrators and Decoders are not
intended for very long-term storage.

Network data gathered by Packet and Log Decoders can be passed through a number
of different filters or “parsers”. The parsing process allows for the creation of useful
metadata (“meta”) to facilitate searching on specific variables, such as reconstructed
sessions between two devices of interest, login attempts by a suspicious user id, or
packet data bound for geographic locations that might indicate a need for further
investigation.
Note that several different kinds of “rules” can be used to filter and manipulate data. In
this graphic you can see Berkeley packet filters at work, along with Network Rules,
Application Rules, and Correlation Rules … all of which together help determine what
data is kept, what is discarded, where it is directed, and what is turned into metadata for
future analysis.
Note that the graphic above depicts a simplified Brokerless architecture, in which no
further aggregation is done beyond the Concentrator.

RSA Security Analytics is a web-based application that you launch in a browser
window.
Compatible browsers include:
• Google Chrome
• Mozilla Firefox
• Internet Explorer 9.x and up
Log on to Security Analytics at https://<SA-IP> where <SA-IP> is the Security
Analytics server IP address.
Security Analytics provides for seven major functions, which correspond to the top-level
main menu choices displayed upon login to the SA Server. Open the UI Main Menu by
clicking on the blue menu bar at the top left corner of the screen.
You can select top-level modules from the Security Analytics main menu. Each module
has its own view, plus sub-views or tabs that provide specific functionality for that
module.

The top-level modules as presented in the UI Main Menu are listed above. A brief
description of their function follows each item. You will learn more about each menu
item as the course progresses.

Some reasons for creating custom dashboards are:
• Consolidate related functionality on single dashboard.
• Customize a dashboard to a particular job role, for example, Security Analyst.
• Create a custom dashboard with a collection of dashlets for top-priority modules.
• Create a dashboard to consolidate dashlets for different network locations.
• Create an overview of a given module's capabilities.
• Consolidate dashlets that apply to a specific scenario.
Each custom dashboard is appended to the Default Dashboard selection list.
Dashlets for all Security Analytics modules are available to add in the default Unified
Dashboard, or to any custom dashboard you may develop.

This module focuses on the functions available under the Investigation>Navigate and
Investigation>Events menu items. Both areas provide you with the ability to examine,
investigate, and manipulate the packet and log data that you have collected.
Malware Analysis is an important part of Security Analytics, but it is beyond the scope of
this course.

The Investigation Module provides your window into the log and packet data you
collect. It provides a set of powerful tools for locating, filtering, and displaying your data,
using a variety of methods and formats.
While raw data is collected and stored on the Decoders, Investigations are usually
performed on the Concentrator or (if your environment includes one) the Broker. The
Concentrators aggregate data from the Decoders, and provide an indexing function that
enhances your ability to locate and analyze data. The Broker aggregates data from
multiple Concentrators. In this classroom environment, investigations will be performed
on the Broker.
You launch an Investigation from the Security Analytics main menu, as depicted above.
Select Investigation, then Navigate to begin exploring the metadata you’ve generated.
At the Navigate screen, you have the option to load all values, or to perform menu
operations prior to loading data. This feature can save unnecessary loading time when
you are working with large data sets. The video-style pause, play, and reload buttons
that appear when you Load Values give you complete control over the loading process.

From the main menu select Investigation>Navigate to arrive at the Navigate Screen.
Once data is loaded, your screen will resemble the one shown above.
The elements displayed at the Navigate screen are collectively termed Metadata. The
Metadata elements are arranged hierarchically, and include Meta Keys, Meta Values,
and Sessions. Each element is in a many-to-one relationship with the element above it
in the hierarchy.
Meta Keys can be created and manipulated by the analyst (if they have permission),
and the analyst can choose which meta keys to gather and display. For example, under
the Meta Key “Source IP Address” you see multiple Meta Values (i.e., multiple IP
addresses); under each IP address, you will typically see multiple Sessions.
Note: Meta Keys are displayed in a black font, while Meta Values are displayed in blue,
and Session Values in green.
The first Meta Key in the list above is “Action Event”: the meta values “get”, “put”, and
“login”, appear as meta values under that Key in the current dataset. Note that each of
those meta values has multiple associated sessions.
The number of sessions associated with a Meta Value is referred to as a Session
Value, and it appears in green. The Investigation Module allows the analyst to drill down
on the session value to inspect the actual contents of logs or reconstructed network
sessions. We’ll take a closer look at this in a moment.
In general, the term Session is synonymous with the term Event. We’ll use the terms
“Session Window” and “Event Screen” to refer to the screen on which the actual
contents of packets and log entries are displayed.

At the Investigation screen, click on a blue Meta Value to pivot or “drill” into a view that
is limited to just that value. For instance, in this slide the analyst has chosen to drill into
just those Action Events that match the value “ip connection denied”.
Notice the “breadcrumb trail” circled at the top of the second screen. The breadcrumbs
always remind you of exactly what drillpoint you’ve reached, and exactly what data
you’re examining. To eliminate the effects of the drill, simply click on the breadcrumb to
see your options for navigating to a different view.
Note that right-clicking on a Meta Value offers you the choice of opening the drillpoint in
a new browser tab, which can make it easier to compare views from different levels in
your investigation. Some drillpoints can go deep into the data, creating breadcrumb
trails that are four or five (or more) elements long.
At any point in the drill, the analyst can switch to viewing the Session data itself. Do this
by clicking not on the (blue) Meta Value of interest, but on the (green numeric) Session
Value. Clicking on the Session Value opens the Event View – alternatively, right-click
on it to open it in a new tab. The Event View offers a look deep inside the reconstructed
packet session or log events of interest.

To drill further into your data, simply continue to click on meta values or session values.
Your breadcrumb trail will get longer, always providing a reminder of the navigation path
you’ve used to get to the current view.
To navigate back to an earlier point in the breadcrumb trail, simply click on the
breadcrumb itself, as shown above. A menu of navigation options will appear.
Removing the breadcrumb trail altogether (“Remove” menu choice) returns you to the
Broker view, where you will see all data aggregated at the Broker.

As we have seen, Security Analytics allows you to construct a Query by clicking on
individual meta values and session values … in effect, navigating by clicking your way
through the data.
An alternative approach is to use the Query feature, available as an item on the

Investigation>Navigate menu bar. Select Query from the Navigate menu, and enter
your query parameters as prompted. You can specify a Simple or Advanced query, and
you can direct it against log data, packet data, or both. The RSA Intellisense query
wizard walks you through query creation at the Simple Query level. Above, you can see
the wizard providing a list of meta keys in the Select Meta area. A drop-down list of
logical operators is provided in the following Operator step. Finally, enter the Meta
Value you want your query to locate.

On this slide you can see the completion of the simple query, executed by the analyst
using the Intellisense wizard in the Query dialog box. The query we’ve created here is
written as action = retrieved. Note how the wizard has translated the Display Name
Action Event into the internal key name action.
If you select the “Advanced” radio button in the Query dialog, you can write your own
query using multiple variables and multiple logical operators. The Advanced Query
requires that you use the actual Meta Key name (“action”) rather than its display name
(“Action Event”). It also requires you to enclose meta value names that contain spaces
in single quotes (for example, action = ‘teardown connection’). Advanced Query also
provides a Wizard to prompt you with available key names and logical operators. When
you’ve finished typing your query syntax, click on Apply.
The Advanced Query is also known as a Custom Drill. It allows you to specify a
complex drillpoint, using multiple keys, values, and logical operators, as depicted in the
graphic above.

Above, you can see the Investigate screen that results from running the Simple Query
built on the preceding screens. Note how the breadcrumb trail reflects the query you
have issued. The screen that results from the complex query would look the same, but
with the complex logic of the query (action = retrieved && ip.dstport = 53) displayed
in the breadcrumb.

A third way of specifying a query is to use the Magnifying Glass icon that appears next
to each Meta Key on the Investigation>Navigate screen.
Click on a Meta Key’s magnifying glass. By selecting a particular Key’s magnifying

glass, you’ve already specified the first part of the query (Meta Key name). The dialog
box that appears now prompts you for a logical operator and a Meta Value to complete
the query. In the example above, the query is User Account = administrator, which
gives you a breadcrumb of username =‘administrator’. Remember the distinction
between Display Names and internal names for meta keys.
Note that only Simple Queries can be constructed via this method. To join two or more
logical expressions into a single query (e.g., action = retrieved && ip.dstport = 53),
select Query from the Navigate main menu and then select the Advanced radio button.

When you’ve reached the drillpoint of interest, you will probably want to investigate the
individual Sessions, or Events, that meet the criteria you specified. In the image above,
you’ve drilled your way into the metadata to a point where the Investigation reveals that,
over the specified time period, there have been 564 sessions in which an IP connection
was denied. Click on the green numeric value to get a closer look at those 564
sessions. This is called the Session (or Events) View.
Remember that if you right-click on the session value, you can open the Events View in
a separate browser tab.

The Events view provides a view of events, or sessions, in various forms. Analysts
might arrive at this screen in a couple of different ways. Many investigations begin on
the Navigate screen, proceed through one or more drillpoints, and wind up on the
events screen when a green numeric Session Value is clicked.
Other analysts might come directly to the Navigate>Events screen (shown above), and
perform their drilling function from the Query item on the menu bar. The Query function
accomplishes the same thing that querying or drilling does at the Investigation screen.
We’ll look at this alternate path through the data in a few moments.
This second navigation path is particularly useful for customers focused mainly on Log
events, for experienced RSA enVision customers, and for analysts who do not need full
access to the Investigation meta screens.
The Events Screen by default presents session information in three standard formats:
List View, Detail View, and Log View. Log View is depicted above, with the drop-down
menu offering alternate views displayed. To see your log data in a different view, select
the view type from this menu.
In addition to the standard forms, you can create a custom view to suit a particular
analysis or monitoring need.

Note that on the Event Screen, the Event Type field identifies this data as coming from
either Network or Log data. The graphic above depicts log data in Log View. Note that
in this view the device (‘Service Type’) is identified, along with a description of the
logged action for each entry. The Logs field displays the raw log data as it was ingested
by the Log Decoder.
Note: if you try to view packet data in Log View, the Logs field will display the message
“Not a log service”. This is not an error message, it’s just a reminder that Log View
doesn’t apply to packet data.

On the screen above, the analyst has used the Navigate screen to drill down on a single
Source IP address, and discovered 4 log events associated with it. The analyst clicked
on the green session value (4), and arrived at this screen. This is the List View, one of
the three standard views offered under the Event Window.
List View displays a summary of the desired sessions. Note that only events with source
IP address 234.158.145.103 are shown here, because that was the drill point in the
investigation. The breadcrumb trail on this screen confirms that.
The List View displays events in a summary format, which enables the analyst to view
multiple events in a single window. This view is very valuable for scanning through a
large number of sessions or events.

Selecting Detail View displays considerably more data per session, but note that each
session now takes up multiple lines. Click on “Show Additional Meta” to expand the
amount of information displayed on this screen. Click on “View Details” to see the Event
Reconstruction displayed in the inset on the slide.
This view is very valuable for examining the details of any single session, but not
convenient for scanning through multiple sessions to locate a particular event.

Starting on the Investigation>Navigate screen and defining your data drill point there
is just one way to arrive at a targeted view of your data.
Another method is to come directly to the Investigation>Events screen, and perform
your drilling function from the Query item on the menu bar. The Query function
accomplishes the same thing that pivoting or drilling does at the Navigate screen. As
noted, this second path is particularly useful for customers focused mainly on Log
events, and for experienced RSA enVision customers.
Note that you can perform several functions at this screen that can also be performed at
the Investigation>Navigate screen. These include issuing queries (equivalent to
setting up a drillpoint, or a custom drill); exporting data files, for external storage and
future use; and setting up Use Profiles, for analysts with specific or limited needs.
You can modify or execute a query from within any one of the three standard view types
(List, Log, or Detail), or from within a custom view that you define.

Create a Custom View by selecting the meta keys of interest, and arranging them in
Column Groups to suit your need. This is not intended as a Reporting function, simply
as a way to conveniently present just the data of greatest interest for a particular
analytic need.
To create a Custom View, work through the Manage Column Groups menu choice on
the Events>View screen. Click the plus sign + to add a column group; click the next
red plus sign to add the specific meta keys you would like to include.
Click Save and Apply when you are done, to create your custom view.

While you may create a Custom View to display the results of a particular query, note
that the display format and the query exist independently of each other. In the example
above, we have issued the advanced query through the Events>Query menu item;
then we applied the custom format through the Events>View>Custom Column
Groups command.

In the graphic above, you can see the result of issuing a complex query, and formatting
the resulting display at the Events screen using Custom Column Groups.

Querying may be the most critical skill to acquire in the Investigation part of Security
Analytics. However, there are a number of options for customizing data display that are
also very important.
The above table summarizes all the functions available on the menu bar at the
Investigation > Navigate screen. Many of these provide you with ways to customize
the display of your data. The next few pages will cover the use of these options.

On the Navigate screen, you can control the display state of each Meta Key by setting it
to one of four possible statuses: Hidden, Open, Closed, or Auto. The Auto state means
that key will only display if it is populated with values in your current data set.
Note that you can customize the display order of meta keys as well. Alphabetize keys
by clicking on the Meta Key header. Once alphabetized, you can resequence keys
however you like by simply clicking and dragging to the desired location.
Consider dragging your most-used meta keys to the top of your Navigate screen, to
reduce scroll time as you perform investigations.

Restricting data to a time range can be done anywhere within the Investigation module.
You may be particularly interested in events that occurred between yesterday evening
and this morning, for instance. You can set the time range for the last 12 hours, to
restrict your investigation to just the events that occurred during that range. The older
data are all still in the database, you’re just temporarily excluding them from view so
that you can focus in on the most recent events. Set your time range back to All Data to
get the most inclusive view.
On this screen the user has chosen to restrict the time range for data to the last 3 hours.
He has also turned on Visualization, by clicking on the Visualization button at the top
right corner of the screen. We’ll return to visualization later in this module.

The Total/Value and Ascending/Descending menu options work together to control the
way your data are displayed. The first is a toggle button with just two options: Order by
Total and Order by Value. Its companion button also has just two values: Sort by
Ascending Order and Sort by Descending Order. Together they allow you to control the
way your data are ordered and displayed on the Navigate screen.
Selecting Value results in an alphabetic sort order (ascending or descending) based

on the name of the value within the meta key. In the example above, the values for the
Meta Key “Source Country” are listed in ascending alphabetic order, beginning with
Argentina and ending eventually with Zimbabwe.
Selecting Total results in a numeric sort order (ascending or descending) based on the
session count for each value within the meta key. In the example above, the values for
the Meta Key “Source Country” are listed in descending numeric order, beginning with
5,771 sessions originating in the Russian Federation, and ending with countries that
have had just a small number of captured sessions.

By the same token, Events can be sorted in either ascending or descending order by
Event Count (number of events), Packet Count , or Event Size (measured in kilobytes).
This button works with the other two to give you a greater measure of control over data
display.

A meta group controls what meta keys are displayed on the Navigate screen, and in
what order. You can use a meta group to limit your display to only a specified set of
meta keys.
To manage meta groups, select Meta>Manage Meta Groups from the Investigation
main menu.

To add a meta group:
1. In the Manage Meta groups dialog box, click Add +.
A new row is inserted at the top of the Meta Groups list.
2. Type a name for the new meta group.
3. Press Enter.
The form is enabled.
4. Under Meta Keys, click Add +.
5. In the Available Meta Keys pop-up menu, select the Meta Keys you want to add to
your group.
6. Click Add +.
7. Click Save.

To change the Investigation > Navigate display so it only shows the metadata in a
meta group, select Meta in the Navigate menu bar, select Use Meta Group, and finally
select the Meta Group you want to use. Once some Meta group other than the Default
has been chosen, the Navigate menu bar will display the name of that group where the
menu item Meta used to be. Notice the Log Events custom meta group circled in the
above example.

The Use Profile option displays a dialog for creating and using profiles that combine
preferred meta groups, column groups, and queries into a set that is selectable from a
drop-down list. Use Profiles are a way of storing and reusing commonly used views,
without having to re-specify the selection criteria every time. Use Profiles are typically
created for individual users, who may benefit from having a specific set of tasks and
views customized for their individual needs. These may be based on job role,
geographic location, security clearance, or whatever other criteria you choose to apply.
The Profiles apply to the Navigate view (meta groups and queries) and the Events
view (column groups and queries) alike.

If the Graphics Display area on the Investigation screen is hidden, click Visualization to
open the graphics bar. Once Visualization is open, you will see an Options button
displayed. Click the Options button.
In the Visualization Options dialog box, choose Visualization – Coordinates, and click
the Plus sign. From here you can add and subtract Meta Keys from the Parallel
Coordinates Visualization dialog.
Select a time range for the Visualization from the Investigation menu. The metadata you
selected will appear in graphical format at the top of the investigation screen. You can
expand the graph area, and highlight specific areas to gather more detail.

The context hub is the centralized context enrichment service for Security Analytics
providing a bridge between SA and sources of context. The hub helps streamline
analysts’ workflow by allowing them to manage enrichments in one place, prioritize data
and add context. The objective of this service is to become the central location for
managing all the context enrichments and provide access to them throughout the user
interface. The initial use cases are focused on investigation.
The context hub is deployed as a service on an event stream analysis host – either
physical or virtual. The administrator has the choice of adding context sources relevant
to their environment. Initially in Security Analytics 10.6 there are three available sources
of context – ECAT (otherwise known as endpoint analysis), IM or incident management
incidents and alerts, and analyst lists.
The analysts interact with the context hub from within the investigation views. As they
execute queries and metadata is displayed or a context lookup request is made, the
request is routed through the context hub to the three sources and any matching
context is displayed in the context lookup panel.

The context hub does not require any additional licensing and the package is installed
automatically when upgrading event stream analysis to 10.6. To minimize potential
resource contention scenarios on the event stream analysis host, especially if it is
already heavy utilized, you can decide whether or not to enable the context hub service.
An installed and enabled context hub uses the database located on the ESA host to
enable communication between the ESA host and the context hub.
Once the administrator configures the sources there are no additional settings to
configure.

Context hub lists can be populated with entries kept as whitelists or blacklists for
analysts to reference during investigations. They can also be used for tagging meta as
an analyst is hunting through events. This allows the analyst to mark a meta value, then
broaden the time range, and still be able to view that tag, for example, if the analyst
finds a malicious host and wants to see if the indicator related to the host occurred
previously.
Lists also provide a way for analysts to collaborate without the overhead of creating
incidents. Once the analyst tags or adds a value into a list, all other analysts can view
that information when doing context lookups.
Analysts can directly interact with the lists stored in the context hub by right-clicking on
a meta value and selecting Add/Remove from List. This enables them to add or remove
entries from an existing list as well as create their own lists and add values to them.

Meta values that are associated with Incidents, Alerts or appear in a list are highlighted
in the Investigation module. You can hover over the value to see where it is found.
Right-clicking the value allows you to select from a list of options, including Context
Lookup, which opens the Context pane to the incident or alert. From there you can
select the incident or alert to view it in the Investigation module. You can also select
Add/Remove from List to add or remove a meta value to or from a list or create a new
list.

There is an expression in English that describes a nearly impossible task: “finding a
needle in a haystack.” A needle is small, a haystack is very large, and the needle and
hay look very similar to each other. So finding the needle in the haystack is nearly
impossible.
Yet that is what Security Analysts are called on to do every day: in the thousands of
gigabytes that cross your network, your job is to find the one or two tiny events that
constitute a real security threat. It’s a lot like finding a needle in a haystack.
How does an analyst approach this problem? Part of the approach will be to “throw out
the hay”. In theory, if we can throw away all of the hay, all that will remain is the needle.
Throwing away the hay is the principle that we’re applying as we start to filter out
“known good traffic.” If we can identify traffic that we know is safe and eliminate that
from our investigation, then the amount of remaining data that we have to analyze is
significantly smaller.
“Known good traffic” is also referred to as “uninteresting traffic” – uninteresting, because
we know that it does not contain the needle that we’re looking for.
An important step in separating the hay from the needle is to develop a clear picture of
what your normal or “baseline” traffic looks like. Understanding what’s normal helps you
to recognize what’s not normal in your network traffic.

As we’ve seen, the Decoders and Concentrators house a database of raw data and
metadata, including session information on all traffic capture. We refer to this data as
the NWDB, or Netwitness Database.
If normal or “baseline” traffic is filtered out of the NWDB, the database size is reduced
and query processing becomes correspondingly more efficient. Queries execute more
quickly and the indexing becomes more responsive. Reducing NWDB size also allows
for more storage space, that can in turn be used to house more historical data that may
turn out to be important. Finally, alerts are more effective if you reduce the number of
false positives based on uninteresting traffic.

Deciding what data to filter out of your capture depends entirely on how your network is
architected. Areas that are considered safe, due to firewall protection, proxy server
placement, internet air gaps, etc., can be eliminated from the collection. Large volume
transfers between trusted devices can typically be eliminated – say, all outbound traffic
between internal networked devices and your local backup server. Other examples will
come to mind based on your individual network design.
If you do not have man-in-the-middle decryption, you should filter out SSL to common
trusted popular sites, such as banking sites, and truncate traffic to all uncommon SSL
sites (same for VPN traffic).

Baselining should be done as soon as possible after packet or log capture is
established, and the Decoder has all content (parsers, rules, feeds, etc.) installed.
Know your baseline content (normal policy-compliant traffic). If there are controls in
place to regulate the traffic and it is trusted, consider filtering it out of the NWDB
capture.
Filter out baseline traffic using a Network Rule or a Berkeley Packet Filter. This makes
abnormal traffic easier to see, and is better for the overall performance and health of the
Security Analytics implementation.
Use Application Rule filters to pare down unwanted traffic using specific conditions. If
there is anything important in what otherwise would be filtered, keep it!
• Create a list of filter rules and have them reviewed by colleagues
• Review filters quarterly to see if traffic patterns have changed
• Validate filters by creating custom drills for the filtered values

The term “Rule” has a number of different meanings in Security Analytics. The three
rule types referenced above are all used to filter traffic, although they are built
differently, and perform somewhat different filtering functions.
It’s important to note that Network and Application rules can be written to filter, truncate,
or keep data. These rules can also be configured to populate meta keys with alert
metavalues when specified conditions are met. We’ll look more closely at the Keep and
Alert parameters of these rules later on in this module.
A note on terminology: these filtering rules are completely different from the broad
category of Reporting and Alerting Rules, which we will also look at later in this course.

The sequence of rule processing is depicted on the above slide. Data flows from the top
to the bottom of the graphic, and is acted on by each rule type in the vertical sequence
shown: BPF rules apply first, followed by network rules, parsers, feeds, and then
application and correlation rules. Most (not all) of these rule types can be used to filter
data out of the NWDB, which is our focus in the first part of this module.
However, these tools can also be used to create and enhance meta data, to generate
alerts, to enrich our investigative abilities, and to allow for enormous flexibility in
reporting, alerting, charting, data visualization, and real-time monitoring of events
occurring on your network. The second part of this module will provide an introduction
to using feeds and rules to build out your metadata to create a more robust analytic
capability.

The network capture interfaces on both decoders can be configured with Berkeley Packet Filters. Note that
Network Rules are available on Packet Decoders only. For that reason BPF may be particularly useful on
your Log Decoders.
Berkeley packet filters were developed for use with the Unix OS and are independent of Security Analytics.
BPF syntax guides can be found at various sites on the Internet: use your search engine to find one that’s
useful to you.
Note: to filter out traffic that meets a specific condition, you must precede that condition with the operator
not. Interpret that “not” as do not keep. Some examples of BPF syntax are as follows:
Drop packets to or from any address in the 10.21.0.0/16 subnet:

not (net 10.21.0.0/16)
Drop packets that are from 10.21.1.2 or are headed to 10.21.1.3.
not (src host 10.21.1.2 or dst host 10.21.1.3)
Combine both IP and HOST:
not (host 192.168.1.10) and not (host api.wxbug.net)
Drop all port 53 traffic, both TCP & UDP:
not (port 53)
Drop all traffic on TCP ports 133 through 135.
not (tcp portrange 133-135)
Berkeley Packet Filters should be tested to ensure that they will yield the expected behavior before
implementing them. For example, you might use tcpreplay to live stream known data to verify that your BPF
is working. Alternatively you can also use either tcpdump or windump. For example:
windump –nni 2 not (port 53 or port 443) or not (ip proto 50)

This rule will filter (exclude) traffic from destination IP 10.10.15.100. Network rules are
applied at the packet level prior to session reconstruction. (This is unlike Application
Rules, which are applied after session reconstruction.) Network rules are made up of
rule sets from OSI Layers 2 through 4.
Network rules can be used to filter out traffic, keep selected traffic, or truncate packets;
they can also populate a specified meta key, as we’ll see in a few moments.
Common use cases for network rules include:
• Filter out all Windows (or other trusted vendor) updates
• Filter out all traffic between internal subnets and a local backup server
Example:
To filter (exclude) traffic on port 80 from 192.168.1.1 OR traffic on port 443 from
10.10.10.1, use this syntax:
ip.src = 192.168.1.1 && tcp.dstport = 80 || ip.src =

10.10.10.1 && tcp.dstport = 443

“Stop Processing” is an important config parameter on both Network and Application rules.
If Stop Processing is selected – once a session matches an application rule, rule
evaluation for that session stops (i.e., that session is not evaluated by the next app rule). If
the specified action is Filter, that session will be discarded before it can be examined by
any other rules farther down in the rule sequence.
If Stop processing is not selected, the session will be evaluated by the next application rule
on the decoder. Security Analytics will run the session against the next rule in the rule
sequence, and so on until a match with a Stop Processing rule is found. This sequential
processing is stopped after any match with a Stop Processing rule is made. Therefore put
filtering rules early in the sequence, so that uninteresting data won’t waste decoder cycles
evaluating it against all of your subsequent rules.
The example on the slide assumes that you trust Facebook login sessions, and want to
eliminate that traffic from clogging up your packet decoder. The rule syntax is:
alias.host = www.facebook.com && filename ENDS login.php

Application rule syntax:
Expr ::= «Field» «operator» «value-list»

• Example: ssn ends ‘5837’, ‘8765’
• Example: ssn ends ‘5387’ && fullname = “Mason Shipley”
Remember that IntelliSense (the rule syntax wizard) is your friend. Also, note that the
Validate button checks your syntax for errors before saving
The rules shown above are simple, but when combined (as in examples 4 and 5 above)
they can access specific sessions very quickly. And time can be of the essence when
working with a security breach.
Consider rule #2: looking for sessions using the Telnet protocol. RSA Security Analytics
goes beyond simply matching UDP or TCP port numbers to standard protocols; instead,
Security Analytics looks at the packet payload to determine if the content itself is
recognized as a particular protocol. Tcp.dstport=23 would reflect normal Telnet traffic
on port 23, but Service=23 will tag all sessions that are utilizing the Telnet protocol,
regardless of the port number actually used.

Application Rules – generate new meta if other meta associated with the same event
meet a specified condition:
• For example, if the protocol is HTTP and the filename is file.php and the action
is POST, then generate a new alert metavalue called zbot activity (or any
other name that is meaningful to you.)
Correlation Rules – generate new meta if a specific event occurs n times within x
minutes. For example, if there are events with the same source and destination IP pairs
and more than 10 different destination ports in 1 minute, then generate the new alert
meta vertical port scan
Live Feeds – generate new meta based on a lookup table provided by the RSA Live
service.
• For example, if the destination IP is within a specific range or on an internal
blacklist, as provided by the Live Service, then generate new alert meta called
Org blacklist.
Custom Feeds – generate new meta based on a information specific to your own
business. These are deployed through the Live module, but the feed consists of
information that you compile and deploy yourself.
Parsers – download or define new parsers specific to the device or data type that
concerns you.

You can search for, subscribe to and deploy source content through the Live Module in
RSA Security Analytics. Once you subscribe to content, it is put in a queue to be
pushed to appliances. Live Manager distributes content based on the settings in the
Live Configuration, typically every six hours. Subscribing to a resource allows you to get
updates automatically. You can also deploy a resource (one-time download) without
subscribing to it on a continuing basis.
Some resources are dependent on other resources. For example, some application
rules are dependent on feeds or parsers. When you deploy or subscribe to a resource,
Live automatically includes the dependent resources as well.
The Live module allows you to manage your subscribed resources as well as create
and deploy custom feeds. Custom feeds are discussed later in this module.

Every meta key is defined by a code entry in an xml file that resides on either a
Concentrator or a Decoder. The great majority of keys are defined on a Concentrator.
The characteristics of the meta key are defined in the file entry. In the example above,
you can see the xml definitions for the “Risk:” keys, which we’ll return to in a moment.
Note that:
key description defines the key display name

name defines the key internal name
format defines the key type (Text, Time, MAC, Binary, IP, etc.)
level defines the database Index Level of the key within the NWDB
defaultAction defines the initial status of the key, which can be modified by the user as
previously shown
Key definitions typically reside in the Index-Concentrator.xml file. Because this file can
be replaced during a routine software update, custom meta key definitions should be
created in the Index-Concentrator-Custom.xml file. The “custom” version of the file
works seamlessly with the default version as a single file, but has the advantage that it
will never be overwritten.
Examine these files on the Concentrator > Config screen, under the Files tab.

After adding new meta key definitions, you will see the new keys in the Investigation
Module. You may need to refresh the Investigation module to see the new keys.
Meta keys can be populated with values from parsers or feeds. Like parsers, feeds can
populate meta keys with new meta values. Feeds typically consist of a .csv list of known
threats (URLs, IP addresses, etc.) They add useful context to metadata (critical server
IP addresses, high-profile users, etc.).
Parsers have many more options but require a level of definition that may be too
complex for an average user. Parsers can do sub-string pattern matches as well as find
multiple values at once.
When creating meta keys, you can specify the Index level for each key on the
Concentrator.
level=“IndexKeys” means that the indexing is done at the level of the key name.
Available operators in Investigation queries will be limited to “exists” and “!exists”.
level=“IndexValues” means that the indexing is done at the level of the meta values
for that key. Available operators in Investigation queries will include =, !=, contains,
begins, etc.
Compare, for example, the fullname and password meta keys (key-indexed) with
value-indexed keys like ip.src and alias.host. Click on the magnifying glass icon next
to these keys to see what query operators are available for each.

The example above demonstrates a taxonomic approach to key creation. Three levels
of risk keys are created, with the risk assessment ranging from low (Risk:Informational)
to high (Risk:Warning).
A taxonomic approach can be taken to both key creation and meta value creation. The
next slide depicts a taxonomic approach to using Application Rules to create new meta
values.

The previous slide demonstrated a taxonomic approach to key creation. You can also
adopt a taxonomic approach to creating meta values under existing meta keys.
We might create a series of application rules (that populate the Alerts meta key for
instance) in a taxonomic way as well. Recall that the name of the Application Rule
becomes the meta value under the Meta Key that the rule populates. We might name a
series of application rules “possible threat”, “probable threat”, and “confirmed threat”, for
instance. We could create reports, alerts, dashboards, etc. to highlight “confirmed
threats” and escalate them into incident queues.
In the example above, the analyst has created a series of rules to populate the alert.id
meta key with precise information about what events have occurred relating to the
manipulation of accounts.

Application Rules are applied at the session level and alert the user to specific activities
occurring in their environment. Application rules can be configured on both the Packet
and the Log Decoders. When specified logical conditions are met, the rule triggers a
specified action. That action might be to filter out a session, truncate the session (keep
the header and drop the payload), or keep the reconstructed session in the NWDB.
With the Alert option selected, the App rule can populate any designated meta key with
a meta value consisting of its own rule name.
Example:
To alert the analyst whenever a router configuration is made, create the following rule:
Rule Name: config:router-change

Condition: event.cat.name=‘config.changes’ && device.class=‘router’
Alert on: alert.id

This rule tracks Facebook logins where filename = ‘login.php’, and populates the Alert
meta key when the rule condition is met.
Note that this Application Rule is not filtering out data, but is keeping data that match
the specified logical criteria. Data that match those criteria are populating the meta key
“Alert”, as specified at the “Alert on” dropdown menu. Any events that match the criteria
will populate the “Alert” meta key with the Meta Value “Facebook Logins”.
Adopting a taxonomic approach, we might have multiple Alert meta values, each named
and defined to track a different kind of alert: Alert.authentication, Alert.malwaredomain,
Alert.accessfailures, and so on. You can be as granular and creative as you like with
the creation and population of meta values.

Stop Rule Processing
If checked, further rule evaluation for a given session ends once the rule is matched,
and the session is disposed of in accordance with the specified action (Keep, Filter,
Truncate). If Stop Rule Processing is not checked, rule evaluation continues until the
session has been evaluated by all the filtering rules.
It is best practice not to use the Keep option when Stop Rule Processing is checked.
Data you intend to keep should be processed by the entire set of rules. Data you intend
to filter should be filtered early, so as not to waste processing capacity by passing non-
interesting data through the entire set of rules.
There are two options you may want to use when selecting Stop Rule processing.
These options do not become available until Stop Processing is checked.
Filter
The session is permanently discarded when it matches the rule.
Truncate
The session payload only is discarded when it matches the rule. Packet headers
and associated metadata are retained.
Alert
When not filtering or truncating to reduce the data set, you may choose to create rules
that flag certain conditions by populating designated Alert meta keys with meta values
of your own creation. In the example above, any session that matches the application
rule logic would populate the Alerts meta key with the meta value “facebook logins”.

Anyone familiar with creating access controls lists (ACLs) for network devices will be
familiar with the principle of establishing a strict order of rule evaluation.
There is a simple guideline for filtering: if you’re going to throw something away (filter it),
do it as early as you can. If the session in question is not a candidate for filtering, allow
all the rules to process it (i.e., do not check Stop Processing on data of potential interest
to your analysis).
Most importantly, remember that order matters. Once you throw a session away,
subsequent rules will not have a chance to evaluate it. Rules that depend for input on
the output of other rules, must obviously fire after those ‘precursor’ rules have done
their work.
Application Rule Alerts: Examples

Client contains Java and file type includes .exe
Zero payload to a threat source
Single packet tcp
Unexpected geo-location in your traffic
Services on an unexpected port, for example, DNS not on port 53
Large volumes of data observed during non-peak hours
Look for 10 failed logins in 10 seconds

Correlation Rules are applied at the session level and alert the user to specific activities
occurring in their environment. Correlation rules are applied over a configurable slice of
time on a Packet or Log Decoder. When the conditions are met, alert metadata is
created and populates the Alert meta key.
Examples:
To detect traffic between pairs of hosts (key=ip.src,ip.dst) where the unique count of
TCP destination ports is greater than 5 within 1 minute, create a rule as follows:
Rule Name: IPv6 Vertical TCP Port Scan 5

Rule: tcp.dstport exists
Instance Key: ip.src,ip.dst
Threshold: u_count(tcp.dstport)>5
Time Window: 1 min
To detect more than 10 failed login attempts within 5 minutes, create a rule as follows:
Rule Name: IPv4 Potential Brute Force 10

Rule: action=login && error=fail
Instance Key: ip.src,ip.dst
Threshold: count()>10
Time window: 5 mins

When the conditions are met, the rule populates the Alerts meta key with a meta value equal to
the name of the Correlation Rule. In the example above, the Alerts meta key would be populated
with one or more instances of “IPv4 Vertical TCP Port Scan 5”.
Note: Unlike Application Rules, Correlation Rules are limited to populating a single meta key,
Alerts. Correlation rules do not offer the options to Filter, Truncate, or Keep data.
In the Rule Name field type a name for the rule. For example, to create the sample rule, IPv6
Vertical TCP Port Scan 5.
In the Condition field, build the rule condition using metadata from the Intellisense window
actions. For example, to create the sample rule type tcp.dstport exists. When this condition is
matched, the session data action is performed.
In the Threshold field, specify the minimum number of occurrences required to create a
correlation session.
• u_count = the count of unique values of the specified key
• sum = the values of the specified key
• count = number of sessions (no key-string needs to be specified)
In the Instance Key field, select the target indicator to base the event upon.
In the Time Window, set the duration during which the threshold must be reached to create a
correlation session.
To save the rule and add it to the grid, click OK.

The rule is added at the end of the grid or inserted where you specified in the context menu. The
plus sign is displayed in the Pending column.
Check that the rule is in the correct execution sequence with other rules in the grid. If necessary
move the rule.

In this scenario, you will consider a situation where multiple attempts to connect to TCP
destination port 80 occur within 1 minute. This situation can reflect an attempt by an
attacker to scan for an open HTTP port as a potential attack vector into a system.
Note: If attempting this exercise in the classroom environment, increase the time
window to five minutes. Data arriving through the File Upload function are processed
less quickly that live data ingested directly from the network.

Parsers are small programs that process raw data feeds (packet or log) to generate
useful metadata.
Feeds leverage existing metadata, and enrich it with additional information.

Threat feeds focus on a specific type of ancillary data, namely the threat indicated by
that meta attribute. For example, you may have a list of web sites that are known to be
associated with malware C2 (command and control) activity. Clearly it is a bad thing if a
host on your network communicates with one of these malware hosts. Thus, a threat
feed can be developed that leverages a list of known malware domains, and runs
against DNS and HTTP hostname aliases looking for any matching activity. If found,
this activity is flagged by applying an additional meta value to the session.
To deploy a feed (from Live or elsewhere) means to download it once. To subscribe to
a feed means that the feed will continue to update itself into the future. Because known
malware domains change over time, you would likely want to subscribe to, rather than
deploy, that feed.
Note that even though Custom Feeds do not come from Live, you deploy a custom feed
through the Live option in the SA menu structure.

Custom Feeds are based on company-specific data, and are created by the user to fill a
specific purpose.
Deploy custom feeds using the Live module in SA.
• However, note that they are not provided by the Live service; you create them
yourself.
Further examples of custom feeds:
• Company Departments based on IP CIDR blocks
• Filename watch lists
• Internal threat intelligence
There is no limit to the type or number of custom feeds that can be created.
Live Module, Feeds View

• Create a Custom Feed or an Identity Feed. Whichever one you choose …
• Click the Adhoc radio button to create a feed that runs once on one or more
decoders
• or, Click the Recurring radio button to create a feed that runs at regular
intervals on one or more decoders
Custom feeds could be created to generate meta based on location, organization, floor,
country, city, etc. This could also be used to create meta based on high value assets,
create specific file watchlists, and utilize internal threat intelligence within an
organization.

The feed can match on one column or multiple columns.

You can always access the feeds you have created or downloaded from Live. Just go to
the Live > Feeds screen, and use the Add, Delete, and Edit icons.

Dynamic DNS is used to keep a specific domain name linked to a changing IP address
when a static IP address is not available or not desired. Dynamic DNS domains are
typically hosted by providers for that specific purpose, where the provider owns the top
level domain (tld) and a subscriber can quickly (and usually freely) register sub-domains
and point them to any IP address they choose. Examples of common dynamic DNS
domains/providers include:
• no-ip.com
• dyndns.org
• changeip.com
• duiadns.net
• dynamicdns.org
• .. many others
When a subscriber registers a subdomain, they are free to pick any name they want
and map it to any IP address they want. For example, one could register
myuniquedomainname.no-ip.org or asnl2349qpwdan.no-ip.org and have them both
resolve to 5.6.7.8, and later change one of the domains to point at a new IP address
9.8.7.6.

Dynamic DNS provides a quick and convenient mechanism for attackers to evade
detection using traditional IP/domain reputation services.

System configuration settings manage the reporting engine service. RSA designed
the default values to accommodate most environments, and recommends that you do
not edit these values because it may adversely affect performance. You can enable
output actions to allow completed reports to be sent to various output mechanisms, and
enable alerts to be sent to the Incident Management module.
Logging configuration settings manage the parameters for Reporting Engine logs,
such as log level and maximum log size. RSA designed the default values to
accommodate most environments, and recommends that you do not edit these values
because it may adversely affect performance.
The IPDB Database Configuration panel allows you to specify the IPDB password
when implementing the IPDB on the Reporting Engine.

SMTP sends an email notification to the user based on the SMTP configuration.
SNMP sends a trap notification to the user based on the SNMP configuration.
Syslog sends all notifications via Syslog messages to a particular host based on the
Syslog configuration. Multiple Syslog servers can be configured on the Syslog
Configuration panel.
SFTP transfers files to a remote location based on the SFTP configuration.
URL publishes output files to a URL.
NetworkShare transfers the output files to a mounted path or shared location based on
the Network Share configuration.

You set up the IM database and notifications in the Configuration module of this course.
In this module, we will focus on creating aggregation rules.

The basic process for creating a report is:
1. In the Rules interface, create a group.
2. Select that group.
3. Create one or more rules for the group.
4. Create a report and add the rules (or create a report directly from a rule).
5. Add text elements to the report.
6. Schedule and view the report.
Once the report is created, you can run it, schedule it to run once or at regular intervals,
create an output action for the report, and view the report.

NetWitnessDB (NetWitness Database)
The NetWitness Database provides meta for rules by extracting the meta from a
Reporting Engine configured to use a Concentrator, Broker or Archiver as a data
source.
IPDB (Internet Protocol Database)

The Internet Protocol Database (IPDB) provides normalized and raw event messages
that can cover significant historical time periods. You need to configure the IPDB
Extractor service and associate it with a Reporting Engine. You can have a number
of IPDB Deployment Scenarios including a multi-site IPDB deployment.
Warehouse DB
If you are using a warehouse in your environment, you can report on data contained in
the warehouse.

The chart definitions are stored in the Reporting Engine, and the data that is plotted is
extracted from a Concentrator.
A chart references the following properties of a rule to create the result set:
• Select
• Where
• Then
• Sort Type
• Limit
Note: Select a valid rule with the properties mentioned above because the chart inherits
the where clause of the rule during run time.
Like reports, rules, and lists, charts are stored in groups.

If you want quotes to be automatically included for the values at runtime, select the
Quotes will be inserted for all the values checkbox. If the checkbox is not selected
and if a value in the list contains a comma, then that value must be enclosed within
single quotes.
Each list value for an IPDB rule must be enclosed within single quotes.
This syntax does not apply to list values for an NWDB rule.
The List Library is a collection of List names that you can use to define a rule.
Parameterized reporting allows you to specify values in the query of a rule dynamically
at runtime without changing the rule definition to view results based on a particular
value.
• At runtime, you can enter the value for the variable or select the value from the list
based on the result set displayed
• The syntax to specify the variable is as follows:
Insert $ before a variable and enclose the variable in braces
Example: columnname=${<variable>}

You can take any rule that exists in Security Analytics and create an alert from it, as
long as that rule has a unique Where clause. After you create an alert, you can add that
alert to the alert queue. After you add an alert to the queue, it runs every minute.
Reporting Engine rules can be converted to App rules to increase efficiency.
Note that other types of alerts include Application rule and Correlation rule alerts in
Investigation (populating meta keys with alert values), and Event Stream Analysis
alerts. Event Stream Analysis alerts are discussed later in this module.

Event Stream Analysis alerts are discussed later in this module.

ESA employs techniques such as detection of complex patterns of many events, event
correlation and abstraction, event hierarchies, and relationships between events such
as causality, membership, and timing, and event-driven processes.
ESA stores alerts and alert meta. Meta is passed through the Esper engine and then
ceases to exist at that point. If an Alert is fired, the necessary meta is stored in the
database, otherwise it is discarded.

ESA Terminology
Rules – The queries (Esper) that when matched trigger alerts
Alert – The output from matching an ESA Rule
Rule Templates – Basic and Advanced
• Used to convert what you write in the UI into code so ESA can understand it
Constituent Event – All of the events involved in an alert, including the trigger event
Rule Library – A list of all the ESA Rules that have been created
Deployment – A list of the ESA Rules that have been deployed to an ESA device

The ESA threat detection framework provides the ability to do automated analytics by
deploying data science modules against ESA data. A generic module is a unit of processing
that accepts an incoming event and outputs another event. This provides the opportunity to
implement many different scenarios. It allows analysts to detect hard to spot threats quickly.
As soon as SA consumes events, they will be processed, scored and aggregated.
The threat detection framework is a configurable analytics pipeline that includes:
• Normalization and transformation, which performs activities like normalizing the
timestamp field, extracting domain fields from alias_hosts, and creating other meta
required by downstream activities like Source IP plus Domain.
• Context and enrichment that allows lookup of whitelists and adding the result to the
event as an enrichment or any contextual information. For example, for C2, the whitelist
will indicate benign domains specified by RSA Live and added to by the analysts as part
of the feedback loop. The added enrichment will be used by downstream activities to
conditionally evaluate scores or perform some action.
• Filters that filter out events that do not satisfy the filter condition. For example,
conditional evaluation inside any activity, such as performing whois lookup only for
beaconing domains or filtering out events for further processing like downstream
activities/scores not being performed/computed for non-beaconing domains. Filters can
be placed anywhere in the pipeline.
• Detection Scoring is specific for each module and will be discussed on the next slide.
• Score Smoothing uses the ‘Rectifier’ algorithm to influence the contribution of a score
over time, smoothing the score such that the score does not drop off rapidly.
The elements of the pipeline can be in any order.

Security Analytics 10.6 introduces the first threat detection framework module,
command and control (or C2) detection. This is a behavioral analytics module that
identifies domains with suspect patterns of communication. It is based on RSA labs
research and is focused on http only. It has been tested for reliability with low false
positives and validated using the EMC CIRC and Lawrence Livermore National Labs
data. It is focused on detection of malware with specific behaviors.
This slide shows the various scores used to generate a final aggregation score that
determines whether an alert is triggered.
The module evaluates HTTP packet data, filters out whitelisted domains, and then
assigns a score for recent content, rare domains with few source IP connections and a
high ratio of connections with no referrer, rare or null user agents, beaconing activity
and nearly expired or recently expired domains. The scores are aggregated and the
aggregation score determines whether an alert is triggered.

This slide illustrates where the C2 scoring fits into the overall threat detection
framework.

Command and control is a common method of execution that leverages social
engineering, such as phishing emails. Command and control is usually the last phase
before there is action on an objective. The link in the email will download the Gh0st
RAT dropper. Once this is installed the dropper will typically generate two local binaries
on the infected host. One of these will be leveraged for cleaning the system of other
malware and security controls (resetting the System Service Dispatch Table to remove
all existing hooks) and infecting the system. The other typically runs as a DLL and is
responsible for managing command and control communications. Once command and
control is established the attacker can send many different commands to the infected
host, including the ability to turn on a webcam or launch a remote command shell.

The advanced configuration settings provide the ability to preserve events for rules that
choose multiple events and improve rule performance.
For rules that choose multiple events, the Max Constituent Events value decides how
many of the associated events are preserved. For example, if a rule fires an alert with
200 associated events and this parameter is set to 100, only the first 100 are preserved
by ESA; the rest are dropped. The default value is 100.
Forward Alerts On Message Bus allows ESA alerts to be sent automatically to Incident
Management.
Debug Rules? enables the debug setting for the ESA logs.
Certain rules require Esper to maintain subexpressions in memory before deciding to
alert on them or not. These subexpressions consume memory and, if left unchecked,
may cause the service to go down with memory exhaustion. For example, for a rule that
uses a time constraint, if the time window is too long and the conditions too loose, you
could have the same rule firing several times and using memory each time. In that case,
the Max Pattern Subexpressions parameter is a safety measure. If a rule exceeds the
specified number of subexpressions, its processing is delayed. The default value is 0,
which means this setting is disabled. You should set a value if there are service stability
issues.
Selecting the Automated Threat Detection checkbox enables the threat detection
framework for use with the C2 module. Additional configuration needed for the C2
module is discussed on the next slide.

To enable threat detection capabilities, deploy or enable the HTTP parser, enable RSA
WhoIs domain registration lookup service by entering your Live credentials in the
UserId and Password fields of the whoisClient in the ESA Explore interface, optionally
upload a whitelist of domains, and enable threat detection in the ESA configuration
interface. Finally, make sure the Suspected Command & Control Communication By
Domain IM rule is enabled in the Aggregation Rule interface of the Incidents
Configuration screen. This allows the C2 module to identify command and control
activity and flag it as an incident. Then wait a day or two to allow the C2 traffic to
discover false positives and normalize.

With Enrichments, you can request lookups into a variety of sources and include the
results into the outgoing alerts. ESA allows you to make connections between EPL
statements and enrichment sources. Once the connections are established, the system
joins the selected fields from the alert output against the information in the sources and
uses the matching data to enrich the alerts.
The system can make multiple enrichment connections and pull contextual data to
make the alert more meaningful. For example:
• ${events[0]["RSADataScienceLookup"][0].score} gives the “risk” score of the
destination domain computed by the RSA Data Science module.
• ${events[0]["orgchart"][0].supervisor} gives the name of the supervisor of the
employee that the alert pertains to (pulled from an HR database).
• ${events[0]["LoginRegister"][0].username} gives the name of the user with the last
successful login from the same ip_src (using a stream based Named Window).

Event Processing Language (EPL) is used to express filtering, aggregation, and joins, possibly
over sliding windows of multiple event streams. It also includes pattern semantics to express
complex temporal causality among events (followed-by relationship).
Once event queries and pattern statements are registered in the Esper core container, events
flow in at real-time speed and trigger arbitrary logic bound to the engine in the form of Java
Objects. This enables leveraging any existing Java technology and ensures easy connection to
existing building blocks.
EPL has two parts: SQL (conforms to ANSI SQL92) and a Pattern Matching Language
(something that SQL does not have). EPL provides complex event processing capabilities and
can perform, but is not limited to the following functions:
• Filter Events
• Alert Suppression
• Compute percentages or ratios
• Average, count, min and max for a given time window.
• Correlate events arriving in multiple streams
• Correlate events that arrive out of order
• On-Off Windows
• Followed-by and Not Followed-by support
• Regex filter support
EPL be written many different ways to solve a particular use case. For more information on EPL
rules, refer to the RSA Security Analytics ESA EPL Rules elearning.

The Security Analytics Event Stream Analysis (ESA) service is capable of processing
large volumes of disparate event data from Concentrators. However, when working with
Event Stream Analysis, it is possible to create rules that use excessive memory. This
can slow your ESA service or even cause it to shut down unexpectedly. To ensure that
this doesn't happen, you can configure your rule as a trial rule. When you configure a
trial rule, you also set a global threshold of the percentage of memory that rules may
use. If that configured memory threshold is exceeded, all trial rules are disabled
automatically.

To create a basic rule, you click the add icon in the Rule Library and select Rule
Builder. In the first section of the Rule Builder, you enter the name of the rule and a
description for the rule. In this example, we are creating a rule that alerts when five
failed logins are followed by a successful login within five minutes. Selecting the Trial
Rule checkbox applies memory thresholds to the rule to avoid performance issues. You
can change the memory thresholds and view a snapshot of memory utilization in the
Health and Wellness, Policies interface. Next you select a severity for the rule from Low
to Critical.

The next portion of the wizard is where you create the conditions for the rule. Click the
add icon to open the Statement window. To add a condition statement, enter a name for
the statement, select whether all conditions or one condition should be met and then
select Add Meta Condition. Enter the values for the condition. In this example, we are
looking for an event description meta key that contains the value failed.
Selecting the Ignore Case? checkbox prevents the rule from failing due to incorrect
case in the syntax. The Array? field indicates whether the contents of the Value field
represent one or more than one value. Select the Array checkbox if you entered
multiple, comma-separated values in the Value field.

You can add multiple conditions to a statement by selecting Add Meta Condition and
entering values and you can add a Whitelist or a Blacklist to the statement by selecting
either of those options.
You can create multiple statements and then use connectors to join them. In this
example, we created one statement for five failed logins followed by another statement
for one successful login. The Group by field allows you to specify one or more meta
keys to narrow the scope of the rule. In this example, we are looking for multiple failed
logins followed by a successful login on a specific device and user. Selecting 5 in the
Occurs Within field sets the time range for this rule to 5 minutes. When you use the
followed by connector, the Strict and Loose options appear. A Strict pattern means that
the alert is triggered when 5 failed login events followed by one successful login event
happen consecutively. Loose pattern means that an alert will be triggered whenever 5
failed login events happen followed by a successful login attempt whether the events
are consecutive or not.

You use a whitelist to ensure that specified events are excluded from triggering the
rule. Whitelists can be based on geographic location or by customer-defined
enrichment CSV sources. In our login example, we could create a whitelist based on
the enrichment source to exclude source users. To add additional conditions to the
whitelist, select Add Sub-Condition.

A blacklist ensures that specified events trigger the rule. Like whitelists, blacklists are
also based on geographic location or by customer-defined enrichment CSV sources. In
this example, the rule is triggering on non-SMTP traffic over port 25 that contains
executables outside of the US. The blacklist excludes US traffic by using the is not
operator.
When you used a GeoIP source for a blacklist or whitelist, ipv4 is automatically entered
for the sub-condition. Enter the meta value for the corresponding value field. For
example, enter ipv4 is ip_src to ensure the GeoIP records are selected based upon the
source IP found in the GeoIP lookup database.

The bottom section of the Rule Builder wizard is where you can add mechanisms to be
notified when an alert triggers. You can be notified via Email, SNMP, syslog or through
a script. The Global Notifications link brings you to the screen where you configure each
of these mechanisms. In this example, email notification is set so the analyst receives
an email when an alert is triggered. The Output Suppression checkbox controls how
many notifications you received and helps prevent an overload of notifications that
could potentially impact performance of systems, such as your mail server. It is a good
idea to enable this setting if you are not monitoring your alerts closely to avoid
performance issues.
The enrichments section is where you add additional context for alerts. In this example,
we have created an in-memory table using a feed containing information about users.
The Settings link brings you to the meta key reference screen where you can check the
syntax of meta keys for your enrichment.
Clicking the Show Syntax button displays the EPL code that is generated for the rule.
Click Save to save the rule.

The purpose of an alert should be to notify you of an event that requires immediate and specific
action. For events that do not require action, or only require you to be aware, you can create a
report. Configure Alert notifications only after your rule testing and tuning is complete. This can
help ensure you do not get flooded with notifications if a rule behaves differently than you expect.
Rules need to be specific so that you limit resource usage. Use the following guidelines to limit
usage:
• Make the filters on the rule exclude all but the necessary events for the rule to fire accurately.
• Make the size of your windows (window time for correlation) as small as possible.
• Limit the events that you include in the window: For example, if you only want to see IDS
events, ensure that you only include those events in your time window.
If you deploy small batches, it's much easier to tell if a particular rule has an issue.
ESA rules are not “one size fits all.” Not all rules will work in your environment. The rule
descriptions tell you which parameters you will need to modify to successfully deploy a rule in
your environment. RSA Live rules have parameters that need to be modified. If you do not
modify your parameters, the rule may not work or it may exhaust your memory.
A common issue is that new rules may cause memory issues. To prevent this, you can set up
new rules as trial rules. Set up thresholds in the Health & Wellness module to alert you if memory
usage is too high. There are metrics in the Health & Wellness module that track memory usage.
You can set up alerts and notifications to send you an email if those thresholds are crossed.
Rules need to be tuned to an alert level that is manageable. If you are flooded with alerts, then
the purpose and utility of an alert is lost. It’s also possible to flood the database (MongoDB) that
stores alerts, which can slow or prevent your system from processing alerts. For example, if you
want to know about encrypted traffic to other countries, try limiting the list to countries that are
known risks. This limits the volume of alerts to a level you can manage. To ensure your database
maintains a healthy level of alerts, configure settings to clear out alerts regularly.

Examples:
What is the logical flow of the rule?
• I need to store the IP of an infected machine and then check each connection
against this blacklist
What are the building blocks?
• I need to identify a failed login based on Windows logs where I can also
identify the username
How are those blocks linked together?
• Event A followed by Event B but not Event C, followed by Event D
How would the expected events look?
• One event containing the action A, another containing action B, both including
a username

Here are some guidelines you can follow when writing and testing your rules.
Can the rule be implemented with the basic rule Wizard?
• If you have multiple statements (combination of meta values in AND/OR),
each repeated multiple times, linked with AND/OR/Followed By, happening
within a single timeframe, then the answer is yes.
• You should plan the different statements and conditions accordingly.
If the answer to the first question is no, then you need to use expert mode.
When using expert mode:
• Carefully select the recipe to use.
• If you struggle after a few attempts, move to a different recipe/approach.
• Use the basic rule builder to create a shell of the statement and customize it.
• See if there is a similar rule in Live.
Check the requirements:
• Are all the meta keys and values available and do all the variables exist?
Check whether the rule is correct:
• Check everything on the EPL Tryout website first.
• Keep the EPL reference guide handy.
• Does the syntax validate correctly?
And finally, make sure the rule works:
• Is the rule triggering?
• Is the alert giving the expected results?

This flowchart helps you determine when you should create a reporting alert versus a
correlation rule alert versus an ESA alert, as well as what type of ESA rule to use.
If metadata exists and you want to be notified when a single event occurs, you should
create a reporting engine alert, or a report.
If you want to be notified when an event within a timeframe occurs, you should create a
correlation rule. If you are not doing either of these, for example, you want to be notified
about multiple events within a timeframe, you should use ESA. If you want to alert on
different events with an AND or OR and followed by, with a single group by and no
distinct key, you can use the ESA basic rule builder. If you have a more complex rule,
you need to use the Advanced rule builder and create an EPL rule.
If you do not have meta, you should create parsers, feeds or application rules to create
the metadata.

C2 incidents display additional data about the incident including an incident summary
with suggestions on how to resolve the incident and icons indicating the type of
behavior identified.


Theoretical

Uploaded by

Copyright:

Available Formats

You might also like

Theoretical

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Theoretical

Uploaded by

Copyright:

Available Formats

RSA NetWitness Logs and Packets®

© 2017 Dell-EMC Corporation

THE INFORMATION IN THIS TRAINING MATERIAL IS PROVIDED "AS IS." EMC

©2017 Dell-EMC Corporation. All rights reserved.

RSA® Security Analytics Foundations DO NOT DUPLICATE 1

Course Objectives .............................................................................................. 5

RSA® Security Analytics Foundations DO NOT DUPLICATE 3

Module 4: Reporting and Alerting ................................................................. 117

RSA® Security Analytics Foundations DO NOT DUPLICATE 4

RSA® Security Analytics Foundations DO NOT DUPLICATE 10

RSA® Security Analytics Foundations DO NOT DUPLICATE 11

RSA® Security Analytics Foundations DO NOT DUPLICATE 12

RSA® Security Analytics Foundations DO NOT DUPLICATE 13

RSA® Security Analytics Foundations DO NOT DUPLICATE 14

RSA® Security Analytics Foundations DO NOT DUPLICATE 15

RSA® Security Analytics Foundations DO NOT DUPLICATE 17

RSA® Security Analytics Foundations DO NOT DUPLICATE 18

RSA® Security Analytics Foundations DO NOT DUPLICATE 19

RSA® Security Analytics Foundations DO NOT DUPLICATE 20

RSA® Security Analytics Foundations DO NOT DUPLICATE 22

RSA® Security Analytics Foundations DO NOT DUPLICATE 23

RSA® Security Analytics Foundations DO NOT DUPLICATE 25

RSA® Security Analytics Foundations DO NOT DUPLICATE 33

RSA® Security Analytics Foundations DO NOT DUPLICATE 34

RSA® Security Analytics Foundations DO NOT DUPLICATE 35

RSA® Security Analytics Foundations DO NOT DUPLICATE 36

RSA® Security Analytics Foundations DO NOT DUPLICATE 37

An alternative approach is to use the Query feature, available as an item on the

RSA® Security Analytics Foundations DO NOT DUPLICATE 39

RSA® Security Analytics Foundations DO NOT DUPLICATE 40

RSA® Security Analytics Foundations DO NOT DUPLICATE 41

Click on a Meta Key’s magnifying glass. By selecting a particular Key’s magnifying

RSA® Security Analytics Foundations DO NOT DUPLICATE 42

RSA® Security Analytics Foundations DO NOT DUPLICATE 44

RSA® Security Analytics Foundations DO NOT DUPLICATE 45

RSA® Security Analytics Foundations DO NOT DUPLICATE 46

RSA® Security Analytics Foundations DO NOT DUPLICATE 47

RSA® Security Analytics Foundations DO NOT DUPLICATE 48

RSA® Security Analytics Foundations DO NOT DUPLICATE 50

RSA® Security Analytics Foundations DO NOT DUPLICATE 51

RSA® Security Analytics Foundations DO NOT DUPLICATE 52

RSA® Security Analytics Foundations DO NOT DUPLICATE 53

RSA® Security Analytics Foundations DO NOT DUPLICATE 54

RSA® Security Analytics Foundations DO NOT DUPLICATE 56

RSA® Security Analytics Foundations DO NOT DUPLICATE 57

Selecting Value results in an alphabetic sort order (ascending or descending) based

RSA® Security Analytics Foundations DO NOT DUPLICATE 58

RSA® Security Analytics Foundations DO NOT DUPLICATE 59

RSA® Security Analytics Foundations DO NOT DUPLICATE 60

RSA® Security Analytics Foundations DO NOT DUPLICATE 61

RSA® Security Analytics Foundations DO NOT DUPLICATE 62

RSA® Security Analytics Foundations DO NOT DUPLICATE 63

RSA® Security Analytics Foundations DO NOT DUPLICATE 64

RSA® Security Analytics Foundations DO NOT DUPLICATE 66

RSA® Security Analytics Foundations DO NOT DUPLICATE 67

RSA® Security Analytics Foundations DO NOT DUPLICATE 68

RSA® Security Analytics Foundations DO NOT DUPLICATE 69

RSA® Security Analytics Foundations DO NOT DUPLICATE 77

RSA® Security Analytics Foundations DO NOT DUPLICATE 78