Envision Architecture

RSA enVi si on Pl atform 4.0 and 4.
1
Archi tecture Gui de
Copyright 2011 EMC Corporation. All Rights Reserved. Published in the USA.
September 2011
Contact Information
Go to the RSA corporate web site for regional Customer Support telephone and fax numbers: www.rsa.com
Trademarks
RSA, the RSA Logo, RSA enVision, RSA enVision Event Explorer, 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 EMC trademarks, go to www.rsa.com/legal/trademarks_list.pdf.
License agreement
This software and the associated documentation are proprietary and confidential to EMC, are furnished under license, and
may be used and copied only in accordance with the terms of such license and with the inclusion of the copyright notice
below. This software and the documentation, and any copies thereof, may not be provided or otherwise made available to any
other person.
No title to or ownership of the software or documentation or any intellectual property rights thereto is hereby transferred. Any
unauthorized use or reproduction of this software and the documentation may be subject to civil and/or criminal liability.
This software is subject to change without notice and should not be construed as a commitment by EMC.
Third-party licenses
This product may include software developed by parties other than RSA. The text of the license agreements applicable to
third-party software in this product may be viewed in the thirdpartylicenses.pdf file.
Portions of this application include technology used under license from Visual Mining, Inc. 2000 - 2010.
Portions of this application include iAnywhere technology, 2001 - 2010.
Note on encryption technologies
This product may contain encryption technology. Many countries prohibit or restrict the use, import, or export of encryption
technologies, and current use, import, and export regulations should be followed when using, importing or exporting this
product.
Distribution
Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.
EMC believes the information in this publication is accurate as of its publication date. The information is subject to change
without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." EMC CORPORATION MAKES NO
REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS
PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
Contents 3
RSA enVision Platform 4.0 and 4.1 Architecture Guide
Contents
Preface................................................................................................................................... 7
About This Guide................................................................................................................ 7
RSA enVision Documentation............................................................................................ 7
Related Documentation....................................................................................................... 8
Support and Service............................................................................................................ 9
Before You Call Customer Support............................................................................. 9
Chapter 1: RSA enVision Topologies ...............................................................11
Single Appliance Site.........................................................................................................11
Single Appliance Interfaces and Event Data Flows....................................................11
Multiple Appliance Site.................................................................................................... 13
Multiple Appliance Interfaces and Event Data Flows............................................... 13
Remote Collectors...................................................................................................... 15
Multiple Database Servers in a Site........................................................................... 16
Enhanced Availability................................................................................................ 17
Security of the Operational Environment.................................................................. 18
Multiple Site Topology..................................................................................................... 18
RSA enVision Software Architecture............................................................................... 20
Data Synchronization in a NIC Domain.................................................................... 23
Data Access................................................................................................................ 24
RSA enVision Content Extensibility......................................................................... 25
Chapter 2: RSA enVision Metadata................................................................... 27
Device Classes.................................................................................................................. 27
Event Message Categories................................................................................................ 28
Message Categories................................................................................................... 28
Message Severity Levels........................................................................................... 29
Watchlists.......................................................................................................................... 30
Device Attributes.............................................................................................................. 30
Device Type............................................................................................................... 30
Device Groups........................................................................................................... 31
Other Device Attributes............................................................................................. 31
Summary........................................................................................................................... 32
Chapter 3: Event Collection ................................................................................... 33
Event Collection Components.......................................................................................... 33
Collection Services.................................................................................................... 34
NIC Collector Service................................................................................................ 36
NIC Logger Service................................................................................................... 37
NIC Packager Service................................................................................................ 37
Device.xml Files........................................................................................................ 37
Event Collection Flow...................................................................................................... 37
Event Storage............................................................................................................. 38
4 Contents
IPDB Filter Index Calculation and Use..................................................................... 39
Remote Event Collection.................................................................................................. 40
Factors Affecting Event Collection................................................................................... 41
Chapter 4: Alerting....................................................................................................... 43
Alerting Components........................................................................................................ 43
Web UI ....................................................................................................................... 44
NIC Web Server Service............................................................................................ 44
NIC Alerter Service................................................................................................... 44
NIC Server Service.................................................................................................... 44
NIC Database Server Service.................................................................................... 44
NIC Logger Service................................................................................................... 45
NIC Packager Service................................................................................................ 45
Alerting Data Flow............................................................................................................ 46
Event Source and Event Message Classification.............................................................. 48
Factors that Affect Execution of Alerting......................................................................... 48
Threads and the Number of Views............................................................................ 48
Device Types............................................................................................................. 49
Correlation Rule Complexity..................................................................................... 49
Watchlists................................................................................................................... 49
Cached Variables, Decay Time, and Multithreading for Variables........................... 49
Output Action............................................................................................................ 50
Vulnerability and Asset Management........................................................................ 50
Chapter 5: Reporting .................................................................................................. 51
Reporting Components..................................................................................................... 51
Web UI ....................................................................................................................... 51
NIC Web Server Service............................................................................................ 52
NIC Server Service.................................................................................................... 52
NIC Database Server Service.................................................................................... 52
NIC DB Report Server Service.................................................................................. 52
NIC Scheduler Service............................................................................................... 53
Reporting Data Flow......................................................................................................... 53
Reporting Tables........................................................................................................ 55
Factors That Impact enVision Reporting.......................................................................... 57
IPDB Directory Structure.......................................................................................... 57
Indexed Event IDs..................................................................................................... 58
IPDB Filters............................................................................................................... 59
DNS Resolution......................................................................................................... 59
Summary Data........................................................................................................... 59
SQL Filters................................................................................................................. 60
Additional Where Clause Filtering in RSA enVision 4.1 Systems........................... 60
Chapter 6: Vulnerability and Asset Management ..................................... 61
Vulnerability and Asset Management Components.......................................................... 61
NIC Asset Collector Service...................................................................................... 62
Contents 5
NIC Asset Processor Service..................................................................................... 62
Configuration Database............................................................................................. 62
Vulnerability Knowledge Database........................................................................... 62
Vulnerability and Asset Management Data Flow............................................................. 63
VAM Extensibility............................................................................................................ 65
Factors that Impact VAM ................................................................................................. 65
Number and Size of AFP files................................................................................... 66
Size of the VAM Database........................................................................................ 66
Index ..................................................................................................................................... 67
Preface 7
Preface
About This Guide
This guide provides information that you can use to help understand RSA enVision
platform data flows and operational factors that can affect system performance. This
guide is for advanced users and assumes detailed knowledge of the enVision platform.
Numbered interactions in the dataflow diagrams imply the general flow of data
through the system. Some numbered interactions are not prerequisites to subsequent
actions, but instead depict alternative flows determined by the specific use case such
as when an action can be triggered by any of several inputs.
The information in this guide covers RSA enVision 4.0 and 4.1 platforms. Features or
capabilities that applies only to enVision version 4.1 are noted.
RSA enVision Documentation
For information about the RSA enVision platform, see the following documentation:
Release Notes. Provides information about what is new and changed in this
release, as well as workarounds for known issues. The latest version of the
Release Notes is available on RSA SecurCare Online at
https://knowledge.rsasecurity.com.
Overview Guide. Provides an introduction to RSA enVision platform features and
capabilities.
Hardware Setup and Maintenance Guide. Provides instructions on setting up and
maintaining RSA enVision appliances. Intended audience is the system
administrator.
Configuration Guide. Provides instructions on configuring an RSA enVision site.
Intended audience is the system administrator.
Migration Guide. Provides instructions on migrating data from a previous version
of the RSA enVision platform to the current version.
Virtual Deployment Guide. Provides instructions on installing an RSA enVision
single appliance site or Remote Collector on a virtual infrastructure.
Administrators Guide. Provides instructions on the basic setup and maintenance
of the RSA enVision platform. Includes instructions for the most common
administrator tasks.
Users Guide. Provides information that helps users to get started using the
RSA enVision platform. Includes instructions for the most common user tasks.
Backup and Recovery Guide. Provides instructions on backing up an
RSA enVision system and recovering from a hardware failure.
Security Configuration Guide. Provides an overview of security configuration
settings in the RSA enVision platform.
8 Preface
Universal Device Support Guide. Describes how to add log collection and
analysis support for event sources that the RSA enVision platform does not
support.
RSA enVision Help. Provides comprehensive instructions on setting up
RSA enVision processing options and using RSA enVision analysis tools.
RSA continues to assess and improve the documentation. Check RSA SecurCare
Online for the latest documentation.
Related Documentation
For information about the RSA enVision Event Explorer module, see the following
documentation:
release, as well as workarounds for known issues.
Installation Guide. Provides instructions on installing the RSA enVision Event
Explorer module on your client machine in separate guides for Microsoft
Windows and Apple Macintosh operating systems. Intended audience is the end
user.
RSA enVision Event Explorer Help. Provides comprehensive instructions on
setting up and using the RSA enVision Event Explorer module.
For information about the RSA enVision EventSource Integrator, see the following
documentation:
release, as well as workarounds for known issues.
Overview Guide. Provides an introduction to RSA enVision EventSource
Integrator features and capabilities.
RSA enVision EventSource Integrator Help. Provides comprehensive
instructions on using RSA enVision Event Source Integrator.
Preface 9
Support and Service
RSA SecurCare Online offers a knowledgebase that contains answers to common
questions and solutions to known problems. SecureCare Online also offers
information on new releases, important technical news, and software downloads.
The RSA Secured Partner Solutions Directory provides information about third-party
hardware and software products that have been certified to work with RSA products.
The directory includes Implementation Guides with step-by-step instructions and
other information about interoperation of RSA products with these third-party
products.
Before You Call Customer Support
Make sure that you have direct access to the computer running the RSA enVision
software.
Please have the following information available when you call:
One of the following:
On a 60-series appliance, the serial number of the appliance.
You can find the seven-character serial number on the chassis tag on the back
of the appliance, or open a Dell Openmanage Server Administrator session,
and click System > Properties > Summary to find the serial number in the
chassis service tag field.
On a virtual appliance, the serial number of the RSA enVision software.
Open the C:\WINDOWS\system32\drivers\etc\Nie-oe.dat file, and locate
the line that begins with S/N=.
RSA enVision software version number.
The name and version of the operating system under which the problem occurs.
On a virtual appliance, the VMware ESX or ESXi server details.
RSA SecurCare Online https://knowledge.rsasecurity.com
Customer Support Information www.rsa.com/support
RSA Secured Partner Solutions Directory www.rsasecured.com
1: RSA enVision Topologies 11
1 RSA enVision Topologies
The RSA enVisionplatform supports two deployment types and three topologies to
satisfy various collection, reporting, and alerting requirements. Topologies denote
whether system components are deployed in a single appliance, in separate,
purpose-built appliances (within a single site), or across multiple sites.
This section briefly describes the most common system topologies, highlighting the
intent of each topology.
Single Appliance Site
A single appliance site is an RSA enVision deployment consisting of one enVision
appliance that provides complete enVision functionalityevent collection, event
storage, administration, and user operationsin a single, purpose-built appliance.
This configuration is intended for small networks within a single geographic location.
The following figure shows a single appliance deployment.
For information on setting up the hardware for a single appliance site, see the
Hardware Guide. For information on configuring a single appliance site, see the
Configuration Guide.
Single Appliance Interfaces and Event Data Flows
Application services (in the A-SRV portion of the system) provides administrative
access for managing user access to the system. User account data is maintained in the
A-SRV portion of the system. Administrators perform data management tasks, such as
setting up directories and disk usage parameters and managing storage locations, in
the D-SRV portion of the system. Administrators also perform collection
management, configuring the system to listen or poll event sources for log messages.
RSA enVision Appliance
Ext ernal St orage Appliance (Opt ional)
RSA enVision Functions
D-SRV Collector
User
A-SRV
12 1: RSA enVision Topologies
Users interact with the system by accessing the A-SRV to run reports. Reports return to
the Administration GUI and may also be routed to other data outputs like e-mail.
Security operations personnel respond to alerts using the standard administration GUI,
the RSA enVision Event Explorer module (an enVision desktop application for
incident management), or using their own external enterprise ticketing system.
The flow of event data begins when logs (event messages) are picked up by the Collector.
All event messages are passed along to the event storage and retrieval function where
they remain available for forensic analysis and reporting. A server in the D-SRV watches
for any event messages defined in correlation rules, passing the target events to the
real-time alert monitoring function for processing by the correlation logic. If a
correlation rule evaluates to true, the RSA enVision system generates an alert within the
Alerting function and sends that alert through configured data outputs to a security
operator.
RSA enVision
Event Collection (Collector)
Data Distribution (D-SRV)
Application Services (A-SRV)
RSA enVision
Administrators
and Users
Alerts
RSA enVision GUI,
E-Mail, Instant Messages
Text Messages,
Instant Messages
External
Ticketing
System
Alerts and
Reports
Security Operations Personnel
Data
Management
Collection
Management
Event Storage
and Retrieval
Data Outputs
Real-Time Alerting
Event Source
Listeners and Pollers
Logs
Event Sources
Hosts and Servers Routers Firewalls
Hubs and
Switches
Laptops and
Desktops
Antivirus
Scanners
IPS/IDS
Administration
RSA enVision GUI,
Event Explorer
Multiple Appliance Site
A multiple appliance site distributes RSA enVision functionalityevent collection,
event storage, administration, and useto three or more separate, purpose-built
appliances. A multiple appliance site can handle a larger number of event sources
distributed over a larger physical area than a single appliance site. An enVision 4.1
system supports up to four configured Database Servers.
The following figure shows a multiple appliance site deployment.
Multiple Appliance Interfaces and Event Data Flows
Administrators, users, and security operations personnel using a multiple appliance
site interact with the RSA enVision system using the Application Services (A-SRV)
just as they do with a single appliance configuration.
Event data flow begins as logs (event messages) are picked up by the Collectors. All
event messages are passed to the event storage and retrieval function where they
remain available for forensic analysis and reporting. Event storage in a multiple
appliance configuration is always located in a centralized NAS (network attached
storage) that is accessed from the D-SRV using a switch (these elements are not shown
in the diagram).
Mul ti pl e Appl i ance Si te
Collector (up to 3 may be installed)
Database Server
(up to 4 may be installed)
Application Server
(up to 3 may be installed)
External Storage Device (required)
ATI Network Switch
A-SRV
User
D-SRV Collector
RSA enVision Functions
A server located in the D-SRV watches for any event messages defined in correlation
rules, passing the target events to the alerting function for processing by the
correlation logic on the appropriate A-SRV. If a correlation rule evaluates to true, the
enVision system generates an alert within the real-time alert monitoring function, and
sends that alert through configured data outputs to the designated security operators.
The following figure shows a multiple appliance configuration with two A-SRVs, two
collectors, and a single D-SRV. For information about additional D-SRVs in a site
(supported by enVision version 4.1), see Multiple Database Servers in a Site.
The following interactions correspond to the numbers in the preceding figure:
1. Administrators configure Database Servers, Collectors, and other Application
Servers using the administration component of the A-SRV.
2. Event source listeners receive events sent by event sources. Event source pollers
request events from event sources using RPC and other client-side methods.
Legend:
Data Di stri buti on (D-SRV)
Event Storage
and Retrieval
Data
Management
Administrative data flows
Event related data flows
Event Col l ecti on
Collection
Management
Event Source
Event Sources
Logs Logs
2
3
4
6
Event Col l ecti on
Collection
Management
Event Source
Appl i cati on Servi ces
(A-SRV)
Administration
Appl i cati on Servi ces
(A-SRV)
Administration
1
Alerts
Alerts,
Reports
Alerts
Alerts,
Reports
5
6
Event Sources
Col l ector Col l ector
2
Data Outputs
Real-Time
Alerting
Data Outputs
5
6
Real-Time
Alerting
3. All events get stored and are accessible by the minute in which they occur, by IP
address, and by device type.
4. Alert filters, watchlists, and correlation rules monitor incoming event messages
and trigger alerts when target messages or target data within messages are
detected.
5. Alerts are passed to Security Analysts interacting with the enVision system using
Event Explorer (the preferred interface), the Administration GUI, or possibly a
ticketing application.
Data Output controls pass alerts and queries over preconfigured channels to the
users who need them.
6. Security Analysts can respond to alerts by researching related events maintained
by the enVision system.
Analysts and other users may run queries or reports against past events.
Remote Collectors
A multiple appliance site supports up to 16 Remote Collectors (RCs), which collect
logs in remote locations and forward the logs to the D-SRV. The following figure
shows a multiple appliance site that includes two remote locations, each with a
Remote Collector. The switch creates a private LAN to interconnect the enVision
components in Location 1. Remote Collectors at Locations 2 and 3 connect to the
D-SRV public LAN connection.
Each remote collector has both D-SRV and LC (but not A-SRV) functionality. These
functions enable the RC to package and store event source messages on its internal
disks. As these internal disks can store only a limited number of event messages, the
RC forwards the events to the site D-SRV for storage on the NAS.
For more information about multiple appliance sites, see the RSA enVision Help topic
Multiple Site Deployment.
For information on setting up the hardware for a multiple appliance site, see the
Hardware Guide. For information on configuring a multiple appliance site, see the
Configuration Guide.
For information on setting up the hardware for a remote collector site, see the
Hardware Guide.
Locati on 2
Locati on 1
Locati on 3
Remote
Collector
Ext ernal
St orage
LC
D-SRV
A-SRV
LC
Switch
Private
LAN
Public
LAN / WAN
Remote
Collector
Multiple Database Servers in a Site
The RSA enVision 4.1 platform supports configurations with up to four D-SRV
appliances in a site. The database server contains the NIC Server Service that
communicates with the external storage (Network Attached Storage) system that
stores event data, asset data, and configuration data. Adding D-SRV appliances
applies additional NIC Server Services that enable the system to handle more access
requests for event or configuration data than could be handled by a system with a
single D-SRV.
This design approach gives customers room to grow their systems as their collection
and processing needs expand by providing the following enhancements over a single
D-SRV configuration:
Increased user/request concurrency
Decreased report execution times for large reports
Increased data access robustness
Improved NIC server session logging with global session ID. Certain messages
include the global session ID which provides the D-SRV name and the type of
data request.
The following figure shows a configuration with multiple D-SRV appliances.
The application server connects to a local NIC Server Service based on configured
communication parameters. A load-balancing function on the D-SRV determines
which D-SRV node handles the request, redirecting the application server to connect
with that node.
Locati on 1
Ext ernal
St orage
LC
A-SRV
LC
Switch
Private
LAN
Public
LAN / WAN
D-SRV
D-SRV
D-SRV
A-SRV
D-SRV
Enhanced Availability
Planned or unplanned downtime of an RSA enVision appliance can lead to the loss of
critical event log information. Organizations can reduce the risk of LC (Local
Collector) downtime by using the Enhanced Availability (EA) configuration.
Enhanced Availability is based upon the Microsoft Cluster Server (MSCS) services in
Microsoft Windows 2003 Enterprise Edition. One or more additional LCs are
provided and configured into the cluster. The cluster role assignment enables
automatic or manual movement of duties from one appliance to another in the event of
appliance downtime.
The following figure shows an EA configuration with one idle Local Collector.
All cluster members monitor LC availability by checking for a heartbeat from each
LC. The Database Server has a permanently assigned DA1 (Data Appliance) role, so it
participates in moving LC roles among appliances as needed, tracking changes in the
site node table. All LCs are configured identically with the same encryption keys.
For planned downtime, an administrator can manually move a CA (cluster appliance)
role to an idle appliance in the cluster, bringing that appliance online. For failover,
available cluster members decide whether and where to move the CA role.
The newly active LC reads its LC designation and role from the site node table. The
LC services read their configuration from the Cluster Configuration Table maintained
in the NAS. In environments using ssh to transfer events to a Collector, all clustered
LCs must be identically configured with ssh keys so that they can operate properly
regardless of which CA role they assume.
Local Collectors use virtual IP addressing so that event sources can find them after a
role change occurs. Outbound RPC calls (Windows collection) use the static node IP.
EA Cl uster
LAN
S
w
i
t
c
h
Local Collector
CA2 Role
Local Collector
CA1 Role
Application
Server
Application
Server
Local Collector (idle)
CA3 Role
Private
Network
Ext ernal
St orage
NAS
Database Server
DA1 Role
Local Collector
CA4 Role
This Collector does
not currently have
the role of LC
Role
Security of the Operational Environment
The RSA enVision platform runs on a hardened operating system that minimizes
attack opportunities by removing unnecessary programs and services from the system.
The OS also improves reliability and availability through the use of patches and
updates that have been pre-tested by RSA.
The RSA enVision platform is assumed to be configured in its own independent
Active Directory domain. This configuration enables the OS to be configured with
appropriate access privileges and hardening requirements according to the
RSA-specified operational environment.
A switch placed between the enVision appliances and the NAS, enables the NAS to be
set up on an isolated private network, reducing the risk of malicious network access.
Multiple Site Topology
Multiple site topologies are referred to as a NIC domain and support enterprise-level
networks with many event sources distributed across a wide (even global) geographic
area. Multiple site deployments consist of two or more multiple appliance sites joined
in a hierarchical master-slave relationship. The following figure shows a simplified
multiple site deployment with four sites.
NIC domains follow a tree topology, relying on a master-slave relationship to resolve
the many possible node locations within such a distributed network.
The root of the tree is the NIC domain master site. Slave sites are next on the
branches. Multiple sites on the same branch preserve the master-slave relationship.
The site closer to the root is always the master of the site farther from the root. A
remote collector site is also a slave to a master site.
Si te 3
Collector
Database Server
Application Server
Collector
Si te 4
Collector
Database Server
Application Server
Collector
Si te 2
Collector
Database Server
Application Server
Collector
Si te 1
Collector
Database Server
Application Server
Collector Slave to Site 1
NIC domain master
Slave to Site 1
Slave to Site 2
Master to Site 4
Site 2 / Location 2
Remote
Collector
This master-slave relationship plays a role in binding together a multi-site deployment
so that event data in one site can be located from other sites in the deployment. See
Data Synchronization in a NIC Domain on page 23 for details.
This master-slave relationship also dictates the order in which configuration changes
are deployed throughout the NIC domain. Changes to the domain master occur first
followed by changes to the slave sites. Along the branches, master sites are always
changed before slave sites. This applies to the following operations:
Installation and configuration.
Migration from earlier RSA enVision versions to newer versions, including
security package upgrades.
Event Source Updates (ESUs)
RSA enVision Software Architecture
RSA enVision software components provide Collection, Alerting, Reporting, and
Vulnerability and Access management functions.
The following figure highlights the major software components that provide enVision
functions and shows the major data flows through the system.
The following descriptions correspond to numbered callouts in the preceding figure.
1. Event Collection provides a variety of individual collection services to collect
data from hundreds of different device types that may be on a network. Some
collection services establish connections to devices and actively poll for new log
data. Other services wait for event sources to send their log data to the enVision
system. Each service implements a device-specific protocol such as SNMP,
ODBC, or MSRPC.
Note that not all collection services are shown.
RSA enVision
Replication
Server
Replication
Client
NIC Database
Server 11 NIC DB
Event
Collection
SNMP Event
Collector
ODBC Client
FW-1 LEA
Event Client
Windows
Event Client
File Reader
External
Ticketing
RSA enVision
Administrator
Vulnerability
and Asset
Scanners
Legend:
Administrative flows
Event related data flows
Mediating data flows
Vulnerability and
Asset Import
Vendor
Vulnerability
Knowledge DB
Device
XML
NIC Server *
IPDB
File System
RSA enVision
User
Security Analyst
Reports, Alert
Handling and
Task Triage
Event
Explorer
Incident
Management
Administration
Synchronization with other
distributed enVision components
in the site or domain.
Administration
GUI
Bulk Data
Export
2
3
External
Systems
4
Output Actions
Run Command
SMS
SMTP
AIM
SNPP
Syslog
Reports
RSA enVision
Configuration
enVision 4.1
7
Asset DB
Vulnerability
KB
SDEE Event
Client
Alerting
Watchlist
1
5
Event
Sources
National
Vulnerability
Database
Event
Source
Update
10
IPDB
Filter
Reporting
8b
Alert
Filter
Query
Filter
ESU / UDS
9
Add Event ID,
Time Stamp, and
IPDB Filter Index
8a
Report
Filter
6
Alerts
NIC DB
2. Collector normalization rules parse and normalize incoming event source
messages, converting them into strings that the enVision system can handle.
The collector uses device.xml definition files to produce message metadata that is
prepended to each message. The message metadata defines aspects of each
message for each supported event source.
The collector prepends an enVision event ID and timestamp to each message to
help interpret and collate the normalized events.
The collector also segregates the messages into one-minute files (each file
contains all messages received within a one-minute interval from a single IP
address). The collector creates index files to speed up processing, adding an IPDB
filter index to the index files. For more information, see IPDB Filter Index
Calculation and Use.
Finally, the collector passes these normalized files to the Internet Protocol
Database (IPDB) file system for storage.
3. The NIC Server Service manages the IPDB, which is the enVision repository for
both translated and raw event messages.
The IPDB is the hub of the enVision system, storing all collected event messages
in a file system organized by device, IP address, and time (year\month\day), as
well as maintaining index files to facilitate searches.
Users retrieve event messages by using report templates or by constructing
custom SQL queries.
4. The RSA enVision 4.1 system includes bulk data export providing historical and
ad hoc data mining to export defined sets of data for external storage or use. A
CLI provides interactive and scriptable modes.
5. Alerting monitors event messages, correlated events, and other conditions such as
certain parameters contained within event messages that are defined to trigger
alerts. Users configure alert views and correlation rules through the
Administration GUI. Filters (part of an alert view set through the Administration
GUI) screen out messages deemed irrelevant, and watchlists are used to parse
messages for target strings including user names, IP addresses, and suspected
domain names.
Alert events are stored in the IPDB through the NIC logger (not shown at this high
level). The alerter polls the NIC database every 30 seconds for any configuration
changes and factors these changes into its behavior. Similarly, the alerter checks
for vulnerability and asset data updates every 5 minutes (default), factoring any
changes into enVision confidence level filtering in the alerter (see callout 7).
6. Security analysts using the RSA enVision Event Explorer module can interact
with enVision alerting for incident management purposes. The Event Explorer
module is a software application that runs on a user PC or laptop. Analysts can
respond to alerts by entering queries to retrieve and examine related events,
escalate incidents, refer events to an external ticketing application, and close
events. All actions are logged as NIC events.
Alerts may be passed to configured output actions to notify analysts that an
incident may need handling.
Analysts use the administration GUI for task triage purposes as well as to define
the events, correlation rules, watchlists, and filters used for alerting.
7. The Vulnerability and Asset Import function provides confidence level filtering to
the alerting function by applying knowledge of specific asset importance and
application and asset vulnerabilities to IDS alerts before those alerts are triggered.
Vulnerability information is gathered from vulnerability scanners, the National
Vulnerability Database (NVD), and vendor-supplied vulnerability data. RSA
enVision Event Source Updates map known vulnerabilities to event sources
supported by the enVision platform. This information is maintained in the
enVision Vulnerability Knowledgebase.
Asset scans contain device, software (operating system), and application version
information, IP addresses, and known vulnerabilities. The enVision system
normalizes this raw information and uses mappings from the Vulnerability
Knowledgebase to create asset signatures (bitmasks) defining the applicability of
vulnerabilities. This information is maintained in the configuration database
(within the NIC database.)
The Vulnerability Knowledgebase and asset database are part of the NIC Database
and all are managed by the NIC database server.
8. Reporting lets enVision platform users run scheduled and ad hoc reports and
queries on event messages stored in the IPDB. The Administration GUI is used to
configure reports and queries and to set filters to tailor the amount of data returned
in a report. All actions are logged as NIC events.
a. All query requests are handled by the NIC Server Service. If IPDB filter
information is available on the data being requested, that information is used
to find the target target data more efficiently. For more information, see
IPDB Filter Index Calculation and Use. If IPDB filtering is not used,
requests are handled by the NIC Server Service which parses each one-minute
file in the IPDB for the target data.
Further filtering may be performed before results are pushed to temporary
report tables.
b. Report results are collected in a temporary report table where additional
filtering is done if specified in the query, before passing the results to users for
viewing.
Reports can trigger output actions such as a notification that a report has
completed or failed. A completed report can also be emailed to a list of
recipients. Reports may also be viewed using the Administration GUI.
9. Event Source Update (ESU) procedures let customers import device definition
files for newly supported event sources as well as updating existing device
definitions. The ESU also provides new and updated reports and correlation rules
and new and updated vulnerability data that is added to the Vulnerability
Knowledgebase.
Event Source Integrator available on the enVision 4.1 platform and Universal
Device Support (UDS) let customers write their own device definition files for
devices not supported by the regular ESU program. See Custom Event Source
Support for more information.
10. The Administration GUI provides an administrator and user interface using the
underlying NIC Web Server Service (not shown in the diagram).
Administrators use the GUI to configure and manage the enVision system.
Configuration and management settings are stored in the NIC Database that is
managed by the NIC Database Server.
Users use the GUI to view the dashboard and to set up, run, and view reports.
Completed reports are stored in the NIC Database.
Security Analysts use the GUI to view the dashboard and to create alerts and
correlation rules (Analysts respond to alerts using Event Explorer).
11. The NIC Database Server manages the NIC database, writing and reading
enVision configuration information in the database as needed. The NIC Database
Server also manages the Vulnerability Knowledgebase and asset database.
In a site with multiple database servers (for enVision 4.1 deployments) or in a
multiple site configuration, the NIC Database Server tracks the locations of all
distributed enVision components for managing replication and retrieval of event
messages from other nodes. Replication client and server components on each
node carry out data transfers for replication and event message retrieval.
Data Synchronization in a NIC Domain
In a NIC domain, RSA enVision configuration and other site data contained in the
NIC database must be synchronized across all sites in a timely manner. This ensures
that users and the enVision system function consistently throughout the domain and
that users can access event data whenever needed. Examples of data to be replicated
includes view configuration information, user accounts, access permissions, asset
fingerprint files, and Event Source Updates.
The enVision network protocol tracks the location information for all sites in a
multi-site environment so that users at any site can find event data at any other site in
the network. The data synchronization scheme relies on the master-slave relationship.
A locator process at each site communicates with the master site to keep the global
device location information synchronized with the other sites in the network.
The following diagram shows how all site data uploads to site 10 (the primary master
site) and how the complete set eventually downloads to all slave sites.
Site 1 uploads its site directory to Site 7. Site 1 gets all the known site directories from
Site 7 (which initially could be none). Similarly, Site 2 and Site 3 also do the same.
Without the Site 7 locator process doing anything over a few iterations Site 1, Site 2,
and Site 3 would all still know about the data on each other site.
Site 7 uploads its site directory along with the site directories for Site 1, Site 2, and
Site 3 to Site 10. This same process occurs for Sites 8 and 9. After a few iterations of
the different locator processes, all the sites have data about all the other storage
hierarchies in the system.
Data Access
Users may authenticate to and access RSA enVision content and functions in two
ways:
The enVision Administration GUI supports browsers connecting over HTTP and
HTTPS if SSL is configured on the enVision system. The GUI provides access to
the dashboard and to the major enVision functions of configuring the system, user
administration, configuring alerts, correlation rules, and watchlists, handling alert
conditions, configuring alert views, configuring, running, and viewing reports and
queries, and viewing and managing vulnerabilities and assets.
The RSA enVision Event Explorer module is a desktop application designed
specifically for incident management. Security analysts interact directly with
enVision alert conditions, responding to them by running queries to confirm or
view events about related network or system activities. The Event Explorer
module tracks the status of incidents from the initial occurrance to the eventual
closed state.
Sit e 7
Sit e 10
Mast er Sit e 10 Mast er Sit e 10
Sit e 1 Sit e 2 Sit e 3 Sit e 4 Sit e 5 Sit e 6
Locator
Locator Locator Locator
Sit e 8 Sit e 9
Upload
Site Info
Mast er Sit e 10
Locator Locator Locator Locator Locator Locator
Download
All Site Info
Download
All Site Info
Download
All Site Info
Download
All Site Info
Download
All Site Info
Download
All Site Info
Download
All Site Info
Download
All Site Info
Download
All Site Info
Mast er Sit e 7 Mast er Sit e 7 Mast er Sit e 7
Upload
Site Info
Mast er Sit e 9 Mast er Sit e 9
Upload
Site Info
Mast er Sit e 9
RSA enVision Content Extensibility
The RSA enVision system may be more closely adapted to customer environments
and tailored to meet specific customer needs by extending or modifying enVision data
and monitoring tools and by providing customized data to tailor enVision functionality
more closely to your needs.
Custom Event Source Support
Users can extend the RSA enVision system to handle messages from new or custom
event sources.
Event Source Integrator (ESI) available on enVision 4.1 platforms is a menu-based
system that customers use to specify device parameters and log parsing information
for new or custom devices. Customers can also generate device.xml files and add the
completed files to the enVision system so that your device appears in the GUI along
with other supported event sources. The event source must be capable of sending logs
using one of the enVision collection protocols such as syslog, SNMP, or log files sent
using FTP.
Universal Device Support (UDS), available on enVision 4.0 platforms, is a command
line alternative to the ESI procedures.
Custom Reports
Users can extend the standard reports provided with the RSA enVision system by
creating customized reports to meet specific reporting needs. Users can copy and
modify standard reports, or create custom reports from scratch.
Custom Correlation Rules
The RSA enVision system provides a variety of correlation rules that monitor events
for indications of well-known attacks and other alert conditions. These rules are
somewhat generic, as the low-level details of a customer network are not known.
Users can customize correlation rules to monitor specific systems for very specific
messages that could indicate an attack or other suspicious activity.
Customers can copy and modify existing correlation rules or they can write rules from
scratch using the Administration GUI.
Correlation rules are grouped into correlation classes defining related families of
correlation rules. The Administration GUI provides screens for entering correlation
rules as collections of circuits and statements modeling specific network behaviors.
Event Source Message Data Access by External Systems
Event source message data may be manually exported (referred to as bulk data export)
for use by external systems.
Bulk data export is provided by a CLI with interactive and scriptable modes. In a
single site deployment, a single bulk data export instance exports CSV data to an
exported file share using the Common Internet File System (CIFS) protocol. This
instance may reside on any D-SRV instance deployed in the Site. Multiple D-SRV
instances, which host the NIC Server process, may be needed to sustain the parsing
load incurred by event extraction, particularly if large volumes of data must be
exported (for example, at a rate equivalent to the rate at which events are coming into
the site).
Event data export capitalizes on the strength of enVision data collection, making the
event data available for use by external applications. The external data is a copy of the
data that is maintained within the RSA enVision IP database.
Import Custom Asset Management Data
Normally, asset management data is imported from asset scanners deployed on a
customer network. The RSA enVision system polls the scanners for their asset scans,
normalizing and importing the asset data from the scans.
By default, the enVision system defines a general set of asset categories and attributes
within those categories. Asset categories are collections of related attributes. For
example, the Category named Organization contains the attributes Company,
Division, BusinessUnit, Department, Group, and Contact, which define actual
parameters.
Some organizations may need to track more attribute categories and attributes than are
provided by default. For example, organizations may want to track a category of
hardware attributes including CPU type, motherboard, RAM, storage type and
capacity, and so on.
The Administration GUI has features for administrators to add new asset categories
and attribute names. After adding the categories and attribute names to the enVision
system, users can use a compatible scanner XML file to define and load the attribute
values. As an example, a user could export assets and their properties from the RSA
enVision system in an XML file. The user can then modify the XML file to include the
new attributes and their values.
The Administration GUI is used to import completed XML files to your scanner. Then
the enVision system can import the completed XML file as a normal asset scan file.
Users can also use the Administration GUI to add a third party scanner that is not in
the list of supported scanners. Users must configure the enVision system to handle the
asset categories and attributes provided by the scanner. Users must also configure
SFTP to poll the scanner for asset (XML) files and define the enVision folder for
storing the XML files.
2: RSA enVision Metadata 27
2 RSA enVision Metadata
The RSA enVision alerting and reporting functions rely on event and event source
identifiers and other data to carry out their operations. These functions examine
variables and other content within event messages from specific event sources to
trigger effective alerts and construct meaningful reports.
Dealing with hundreds of event sources and many thousands of possible event
messages to find specific variables or other data would pose a daunting task for
analysts. The RSA enVision system provides several kinds of metadata to help
organize event sources and event messages into more manageable groups or
categories and to facilitate examining messages for specific variables or strings. Most
of this metadata is available to users for defining classes or categories of objects of
interest. Understanding the purpose and use of enVision metadata is essential for
efficient use of alerting and reporting functions.
This chapter describes the following types of enVision metadata:
device classes and subclasses
message categories and severity levels
watchlists
device attributes including:
device type (dType)
device groups
A summary at the end of this chapter compares the usage of these metadata structures.
Device Classes
The RSA enVision system supports hundreds of different event sources and groups
these event sources into device classes and subclasses that you can use to quickly
focus alert monitoring onto specific kinds of event sources in your network. Device
classes can also be included in device groups (see Device Groups) that can be used
to filter reports.
The following table shows the four device classes: Security, Network, Host, and
Storage. Columns list the device subclasses for each class.
Security Network Host Storage
Access Control Configuration
Management
Application Servers Storage
Analysis Router Mail Servers Database
Anti Virus Switch Mainframe
28 2: RSA enVision Metadata
The enVision format for showing the device classes and subclasses in the GUI is
deviceclass.subclass. An example is Security.Firewall. You can view the assignment
for each supported event source in the enVision GUI by clicking Overview > System
Configuration > Devices > Manage Device Types.
Users can include the device class and subclass in alerts and correlation rules to focus
the operation on specific parts of the infrastructure. The device class also appears on
the Enterprise Dashboard indicating which part of the infrastructure is most affected.
Event Message Categories
The RSA enVision system assigns event messages to message categories and message
severity levels to help users choose appropriate event messages for altering and reporting.
Message Categories
The RSA enVision system supports many thousands of different event messages. Each
event message is assigned to a message category. A message category indicates the
type of message, offering a way to alert and report on similar messages - even when
those messages are from different event sources. The top level is called the NIC
category. These broad message categories are named:
Attacks
Reconnaissance (such as port scans)
Content (web content events, such as normal transactions or suspect requests)
Authentication (authentication events)
User (such as logon and file access)
Policies (such as firewall rule events)
System (hardware errors)
Configuration (administrator modifications)
Network (such as usage or routing errors)
Other
Application Firewall System Midrange
Anti Virus Wireless Devices Unix
DLP Virtualization
Firewall Web Logs
IDS Windows Hosts
IPS
VPN
Security Network Host Storage
Each of these categories is divided into alert categories and further divided into event
categories. The format for displaying message categories in the GUI is a dot-separated
name: NICCategory.alertCategory.eventCategory and a corresponding ten-digit
category ID. For example the message category Network.Connections corresponds to
message category ID 1801000000.
You can see the message category assignment for each supported event source in the
enVision GUI by clicking Overview > System Configuration > Messages > Manage
Categories.
The following figure shows a five-level message classification, as well as the syntax
for specifying categories when configuring alerts or conducting an analysis.
Use the message category to monitor for alerts based on event messages within
specific event categories. Use the category ID to identify the category type in where
clauses when creating reports that use the Global table (the Global table defines
generic parameters for event messages). Users can add their own message categories
(and then subsequently modify or delete them) but they cannot modify or delete
categories provided with the RSA enVision system.
Message Severity Levels
Level categories are single-digit IDs from 1 to 7 that group various alert conditions
based on their severity. Each event message maps to an alert level. Use the alert level
to monitor the importance of the different alerts occurring at a specific level. The alert
levels are as follows:
0-1: Emergency or panic conditions that should be corrected immediately.
2: Critical conditions that should be looked at immediately.
3: Error conditions.
4: Warning conditions.
5: Notification messages. Messages that are not error conditions, but may require
special handling.
6: Informational messages.
7: Debugging messages.
Note: Message categories are referred to as event categories in some places in the
RSA enVision GUI.
Attacks.Access.Informational .Network Based.TELNET
NIC Category
Alert Category
Event Categories
Watchlists
Watchlists are user-defined named collections of strings that represent lists of
like-values such as user names or IP addresses. Watchlists provide a dynamic
approach to processing views and reports. That is, as watchlists are modified, report
definitions and alert views relying on them automatically pick up these new values.
Watchlists contain strings of special interest. For example, a single failed logon
attempt may not be of interest, unless the attempt is made by a terminated employee.
The alert view uses a watchlist containing names of terminated employees to scan all
event messages for these names, triggering an alert when a match is detected.
Watchlists can be used in event traces (in the RSA enVision Event Explorer module)
and as a filter when creating an alert, correlation rule, report or query.
Watchlists can be created and viewed in the GUI in Overview >System
Configuration >Watchlists >Manage Watchlists.
Device Attributes
The RSA enVision system supports hundreds of different event sources that may be
used for alerting and reporting purposes. Event source criteria provided with the
enVision system consists of the device type which uniquely identifies an event source
such as a Check Point Firewall-1 or a Cisco-PIX firewall. Users can also define device
groups. Device groups are named collections of event sources based on IP address,
device type, or other user-defined device attributes.
Device Type
The RSA enVision system uses the device type parameter (abbreviated dType) to
identify a specific event source type.
The dTypeparameter is defined in the device initialization file (eventsourcename.ini).
The paremeter consists of a name and a numeric value. For example, the Check Point
FireWall-1 dTypeis checkpointfw1, 3. The name (checkpointfw1) is for human
consumption in the GUI, reports, and queries. The numeric value (3) is used internally
by the enVision system to find the correct parsing data in the device.xml file to parse
against.
The device type value may be used in report SQL where clauses to limit reports and
queries to specific event sources.
For example, a report requesting firewall data causes the NIC Server Service to pull
data from several firewall event sources including Check Point FireWall-1, CiscoPix
Firewall, CyberGuard Firewall, Palo Alto Networks Firewall, and SonicWALL
Firewall. You can use the dType parameter in an SQL where statement (such as
...where dtype=n) to limit the final data in the report to be from a single
firewall event source type.
You can see the device name and dType parameter for each supported device in the
RSA enVision latest update package Help.
Device Groups
A device group is a named collection of event sources that can be included in a report
or correlation rule to filter results. Device groups provide a mechanism to limit access
to device data. Device groups can be set up to both control what data a user is allowed
to see along with being a convenient method to filter data. For instance, data being
viewed in a report or alerted on can be filtered using one or more device groups.
Device groups can specify event sources based on criteria such as IP address, device
name, device type, device class, and device attributes.
A device group dynamic filter is resolved to the IP addresses each time the filter is
applied so that event sources may change.
A device group static filter is resolved to the IP addresses when it is created so that
event sources, once defined, do not change.
Other Device Attributes
In the context of a network, event sources have additional device attributes such as
department or organization, system administrator, and importance within the
organization.
Users assign these attributes to event sources. This information can be viewed and
managed using the enVision GUI by clicking Overview > System Configuration
>Devices > Manage Monitored Devices. The information may also be imported in
bulk. The default categories for device attributes are as follows:
Properties
Location
Organization
Owner
Physical
Function
Importance
Vulnerability
Zone
SystemInformation
Each category is made up of attributes. For example, Importance has a single value
that can be set as needed, and Physical has attributes for Manufacturer, SerialNumber,
AssetTagNumber, Voltage, UPSProtected, RackHeight, Depth, and BTUOutput.
Users can add new categories and attributes as needed.
The device discovery process of the collector assigns each device a certain number of
attributes such as the device type, collection state, and device class. Users can specify
additional attributes using either the Manage Monitored Device or Import/Export
Device user interfaces. These attributes can then be used in alerting and reporting in
various forms of filtering to limit events being considered.
Summary
The following table summarizes the metadata types.
Metadata Example Usage
device class groups similar
types of event sources
together using a string
formatted as
deviceClass.subclass.
All firewall devices are in the
fireweall.security device
class
Used to filter alerts and
correlation rules. Can be
included in a device group
to be used in a report or
correlation rule.
message categories group
similar types of event
messages together
Messages in the message
category Attacks.Access
represent a general threat to
the network and should be
monitored closely.
correlation rules. Also used
in where clauses for reports
using the Global table.
message severity levels
prioritize event messages by
severity (debugging and
informational to emergency
messages)
Messages of level 0 and 1
represent emergencies and
alerts where the system is
unuseable and needs
immediate action.
correlation rules. Also used
in where clauses for reports
using the Global table.
watchlists can contain
strings of special interest to
security analysts.
Watchlists can contain strings
such as source or destination
IP addresses, user names,
event IDs, and so on.
Used in Alerting to look for
specific strings in incoming
event messages.
device attributes define
implementation-specific,
user-defined, and
RSA-defined attributes for
event sources
Users must input these
attributes such as Location,
Owner, or Importance.
Can be included in a device
group to be used in a report
or correlation rule.
device type (dType) is a
device attribute that identifies
individual event sources
The device type identifiers
for Enterasys Dragon IDS is
dragonids, 51.
Used in Report where
clauses
device groups define a
collection of event sources
having same device
attributes.
Create a static device group
to specify one or more device
attributes.
Used to filter results returned
from the IPDB or to filter in
an alert or correlation rule.
3: Event Collection 33
3 Event Collection
This chapter describes the components involved in event collection and describes the
flow of event data through these components. The chapter also describes factors
affecting event collection.
Event Collection Components
The event collection components consist of various collection services, NIC agents,
the NIC Collector Service, and the NIC Packager Service. The collection services
each support a specific collection protocol, such as Check Point (LEA), Windows, or
SNMP. Each of the collection services relays event messages to the NIC Collector
Service through a shared memory interface.
The NIC Collector Service collects the event messages received from the collection
services, as well as messages received through UDP and TCP protocols, and passes
them to the NIC Packager Service as one-minute files. (One-minute files contain all
event messages for a single device received within a sixty second time period.) The
NIC Packager Service unpacks the messages and reorganizes them by device type,
event source IP address, and date and time for storage in the Internet Protocol
Database (IPDB) along with index and summary files.
The following figure shows the components involved in event collection.
Event Collection Components
Collection Services
NIC
Windows
Service
NIC
ODBC
Service
NIC
Trapd
Service
NIC File
Reader
Service
NIC
WinSSHD
Service
NIC SDEE
Collection
Service
Index and
Summary Files
To IPDB
Event
Sources
NIC Database Components
(supporting all services)
Synchronization with nic.db
databases on other nodes in
the domain.
Replication
Server and Client
Configuration
Database
NIC
Database
Server
Service
nic.db
NIC
Packager
Service
NIC FW-1
LEA Client
Service
One-Minute Files
Event Sources
Logfile Device
Syslog
Event
Sources
Internal
enVision
Events
Logfile Device
SFTP
Plaintext
Logfile Device
NIC
Logger
Service
NIC
Collector
Service
NIC
Win 2008
Service
NIC
VMWare
Collection
Service
34 3: Event Collection
Collection Services
NIC File Reader Service
The NIC File Reader Service collects events from log files. Event sources generate log
files that are transferred using FTP or SFTP to RSA enVision appliances containing
the NIC Collector Service and collection services. The NIC File Reader Service uses
different modules (DLLs) to parse the various log file formats. The NIC File Reader
Service sends the parsed log events to the NIC Collector Service through a shared
memory interface.
NIC FW-1 LEA Client Service
The NIC FW-1 LEA Client Service is the collection interface to Check Point Firewall
logs. The service leverages OPSEC LEA, a Log Extraction Agent to pull logs from
Check Point event sources.
Two RSA enVision processes, the Check Point Service (pi_checkpoint) and the Check
Point Collection Process (cpprocess), handle the collection of log records from Check
Point servers. The Check Point Service runs as a NIC service under the control of the
Windows Service Control Manager and is responsible for the following:
Creating the configuration files used by each Check Point Collection Process
Starting a Check Point Collection Process for each Check Point server that you
configure
Monitoring the status of each Check Point Collection Process and restarting the
processes if necessary
The Check Point Collection Process is responsible for the following:
Collecting the log records that the process is configured to collect from the Check
Point server
Monitoring the status of the Check Point Service and shutting down if the service
shuts down
Creating and maintaining the position file associated with the server from which
the process is configured to collect
For loading purposes, the enVision platform uses permanent or temporary
connections. A temporary connection is used with a Check Point server that does not
generate many events. A permanent connection is used with a Check Point server that
generates a large number of events.
NIC ODBC Service
The NIC ODBC Service collects events from database systems using the Open
Database Connectivity software interface.
NIC SDEE Collection Service
The NIC SDEE Collection Service collects events from Cisco Intrusion Prevention
Systems. This service is an HTTPS client process that connects to IPS event sources to
poll for log files.
NIC Windows Service
The NIC Windows Service collects events from Windows PCs and servers. This client
process makes Microsoft remote procedure calls to retrieve log files.
NIC Windows 2008 Collection Service
The NIC Windows 2008 Collection Service (available on enVision 4.1 systems)
collects event data from recent Windows Operating Systems including Vista, Server
2008, and Windows 7, using WS-Management services. Administrators must
configure connection parameters, time interval, event queries, and device type
mappings.
For connecting to systems that use Windows Remote Management authentication and
message encryption, administrators must take additional configuration steps. The
collector service supports the following authentication methods:
Basic/Digest Authentication
Negotiate Authentication
Kerberos Authentication
Certificate Authentication
CredSSP Authentication
NIC VMWare Collection Service
The NIC VMWare Collection Service enables event collection from VMware
management servers. The service implements a VMware infrastructure (VI) SOAP
Client that retrieves aggregated events for VMware ESX, ESXi, and VC from a
VMware Virtual Center Server through the VI API. The VI Client sends requests to a
VI API at a default interval of 15 minutes. The minimum interval value is one minute.
The service keeps track of the events that it has already sent to the RSA enVision
system and does not transmit multiple messages that correspond to the same VMware
event.
The service implements a data converter that transforms VI-formatted events into a
normalized enVision format. After retrieving events from a VI API resident on a
Virtual Center Server, the converter parses each event, transforming events into a
format that can be transferred over UDP and interpreted by the enVision system.
An administrator configures the service by editing a properties file defining:
the interval at which the VI Client shall retrieve events from the server.
the URL of the VI API with which the VI Client communicates.
username and password required to authenticate to the virtual infrastructure.
a server certificate for communication with the VI API when the VMware
Collection Service is configured for HTTPS.
parameters to throttle the rate at which events are pushed to the enVision syslog
parameters.
NIC Trapd Service
The NIC Trapd Service is a daemon process on UDP port 162 that listens for SNMPv1
or SNMPv2 events and traps.
The NIC Trapd Service uses three methods to collect traps. Each method uses specific
DLLs that are explicitly loaded by the main SNMP process based on the event sources
that are configured:
The preferred method uses the Parser Trap Handler DLL, which interacts with
specification files to translate traps to syslog messages. A specification file exists
for each device type.
For some event sources, a DLL that is specific to the event source translates traps
to the syslog format. If you configure the RSA enVision system to receive traps
from these event sources, the enVision system loads these DLLs.
For configured event sources that do not use either of the preceding two methods,
the Universal Device Collector DLL reads configuration data from the NIC
database to determine how to translate traps from those event sources to syslog
messages.
NIC WinSSHD Service
The NIC WinSSHD Service listens for SSH connections from event sources sending
log files to the RSA enVision system. The NIC WinSSHD Service also accepts
connections from NIC SFTP Agents on Windows systems that do not have their own
FTP or SFTP capability.
NIC SFTP Agent
The NIC SFTP Agent is supported on Microsoft Windows 2000, 2003, 2008, and XP
operating systems and must be installed on event sources that do not have internal
FTP or SFTP agents. Systems requiring the NIC SFTP Agent include Cisco
CiscoWorks, Microsoft Exchange Server, Microsoft IIS, and Oracle running
Windows. For a complete list of these systems, see the RSA enVision Help topic
RSA enVision NIC SFTP Agent Configuration.
The NIC SFTP Agent pushes data to the NIC Collector Service through either the
Microsoft FTP Server (only for IBM iSeries) or WinSSHD. The files are processed
through the NIC File Reader Service to shared memory.
NIC Collector Service
The NIC Collector Service is the main collection process in the RSA enVision system.
The service uses a temporary directory structure on the D: drive (located on the
Collector in a multi-appliance site) to organize incoming events into one-minute files.
This service exists on the single appliance or, in a multiple appliance site, on Local
Collector (LC) and Remote Collector (RC) nodes. The NIC Collector Service interacts
with a set of protocol-specific collection services and aggregates all events coming
from the event sources.
In addition, this service supports two built-in protocols: UDP and TCP. The UDP
collection thread can collect between one and four UDP ports depending on specific
event source configurations. Usually, only port 514 is used. The TCP collection thread
can handle up to 128 event sources simultaneously. Dropped and improperly closed
connections, however, may result in fewer than 128 actual simultaneous connections.
UDP and TCP provide support for the syslog protocol.
NIC Logger Service
The NIC Logger Service collects internal events generated by RSA enVision system
components. This service exists on the single appliance or, in a multiple appliance site,
on the D-SRV and RC nodes. This service is similar to the NIC Collector Service, but
it is specifically dedicated to collecting NIC system events for a single or multiple
appliance site.
NIC Packager Service
The NIC Packager Service processes the one-minute files. The processing includes
reading the files and creating an index file that optimizes and facilitates access to the
messages in the one-minute file by event ID. Additionally, the service creates
summary files that contain counts and accumulated data from the messages. Finally,
the service compresses the three types of files (one-minute files, index files, and
summary files) and stores the compressed files into five daily archives in the IPDB,
the data store containing all event messages that have been received.
On the D-SRV node, the NIC Packager Service packages the NIC system events
occurring on the site for all nodes in the site. In a single appliance site or RC node,
a single NIC Packager Service packages events from event sources and NIC events
from the RSA enVision system.
Device.xml Files
Device.xml is a collection of xml-formatted definition files that map event source
messages to message metadata defining aspects of each message for each supported
event source. The RSA enVision system prepends some mapped metadata to event
messages when storing the messages in the IPDB.
Reporting, alerting, and query operations rely on the prepended metadata and other
mappings provided by device.xml files.
Event Collection Flow
The NIC Collector Service aggregates the messages collected by the collection
services, and then segregates the messages into one-minute files based on the device
type and event source IP address.
For each one-minute file created by the NIC Collector Service, the NIC Packager
Service creates a one-minute .dat event file (discarding the original one-minute file).
The packager draws event metadata from device.xml files to prepend to each message
in the one-minute .dat event files. The metadata ensures that the RSA enVision system
can find and interpret the messages during lookups for reporting, alerting, and query
operations.
The packager creates index files and summary files to speed up queries and reports
and to support summary report generation. For each one-minute file, the packager
calculates an IPDB filter index to indicate the presence of specific variable values in
messages contained in the file, storing each index in the index files. For more
information, see IPDB Filter Index Calculation and Use.All files are compressed
and stored incrementally, in the chronological order in which they are received, into
the daily archives.
The NIC Logger Service produces one-minute files containing internal enVision event
messages, passing them to the packager for processing.
The following figure shows the data flow through the Collector.
If data is collected from an event source during every minute of a day, there are 1,440
event files in the .dat archive (60 each hour for 24 hours), 1,440 index files in the .idw
archive, and 1,440 summary files in the .sdw archive. Every hour, a summary file
aggregating the 60 index files and a summary file aggregating the 60 summary files
are created. These two files are compressed and stored in the .isw and .ssw archives
respectively. Both of these archives contain 24 files at the end of the day. Each event
source being collected from has a separate set of these five archive files for each day.
Event Storage
The NIC Packager Service processes the one-minute files and stores the processed
event messages, summary data, and index data in the IPDB file system. The IPDB is a
purpose-built file system with a hierarchy of directories facilitating quick lookup. The
service organizes the data from each Local Collector by IP address, time, and event
category for fast lookup by alerting and reporting operations.
Collection
Services
1
Event Files
*.dat
Index Files
*.idw
Summary Files
*.sdw
Index Summary
*.isw
Summary Summary
*.ssw
IPDB Fi l e System
NIC
Server
Service
NIC
Trapd
Service
NIC
Packager
Service
1
Partial list of collection services
NIC FW-1
LEA Client
Service
NIC
Windows
Service
NIC
Collector
Service
NIC Logger
Service
Internal
enVision
Events
Device
XML
Syslog
Event
Sources
One-Minute Files
One-Minute Files
Log/event data (one-minute files) that are stored in the IPDB include an integrity
verification code that can be checked using an RSA enVision utility called
lsmaint.exe. The enVision 4.0 platform uses a CRC-32 error detection code. The
enVision 4.1 platform uses a SHA-256 hash.
The following diagram shows the structure of the IPDB file system and explains the
content of one-minute files.
Index and summary files contain information about the message types contained in the
event data objects to allow for quicker access to data that is requested during IPDB
queries. The index data is stored in three levels associated by time duration:
Index files (.idw) contain an index to the byte offsets for objects in the .dat files
and statistical information about the number of events of each type and the
associated size in bytes. These files help queries and reports to generate results
more quickly.
Summary files (.sdw) contain one-hour summations of the objects in the .dat file.
The summations are used for summary reports.
Index summary files (.isw) contain an index to the .idw index files. This index
helps queries and reports to generate results more quickly.
Summary summary files (.ssw) contain one-day summary roll-up information that
is used for summary reports.
The RSA enVision system provides tamper-evident protection of the data using the
integrity values in the one-minute files. The system also protects the data with access
authentication.
IPDB Filter Index Calculation and Use
The RSA enVision 4.1 system includes IPDB filter indexing to speed up reports and
queries. An IPDB filter is a space-efficient probabilistic data structure that is used to
test whether an element is a member of a set. False positives are possible, but false
negatives are not.
Event Files
*.dat
One-Mi nute Fi l e (Event Fi l e)
IPDB
\envi si on
\l snode
\data
\col l ector name
\ devi ce type
\ IPaddr
\ yyyy
\ mm
\ dd
1440/day
Index Files
*.idw
Summary Files
*.sdw
Index Summary
*.isw
Summary Summary
*.ssw
1440/day
1440/day
24/day
24/day
Header metadata about the messages in the file:
- an indicator if the coding is unknown or is UTF-8
- version number of the file structure
- offset to the start of the first event in the file
- integrity value for the events contained in this file
- number of events in the file
- UTC starting time for this container
- UTC ending time for this container
- size of the events in bytes
- 20-character device type name
Message one or more events separated by a
single line feed character (\LF). Each message is
prepended with a metadata signature containing
the source device from which the event came, the
collected UTC time at which the event was
processed, the normalized event ID, and the offset
into the file where the event is located.
The NIC Packager service reads the raw one-minute file passed from the NIC
Collector Service and parses the event messages for specific variable values. After
parsing, the Packager calculates IPDB filter indices for each variable. On a match, the
parser sets those IPDB filter parameter indices to 1. Hash functions are used to
calculate the index positions and these functions are not guaranteed to be collision
free. Consequently, some indices may belong to more than one variable value, a
condition that can lead to a false positive.
On reading data from the IPDB, the NIC Server Service recalculates the IPDB filter
value and checks whether the indices are all '1'. If so, the NIC Server Service reads the
events from the corresponding one-minute .dat file.
The following figure shows the Packager storing the IPDB filter index in the header of
the minute, hourly, and daily index files.
Reports and queries typically contain specific parameter values as search targets.
Without IPDB filters, the NIC server service must always search each relevant
one-minute file in the IPDB, parsing all contained messages to look for the target
parameter values. Using IPDB filters, the NIC Server Service can just check the IPDB
filter index to determine whether the target parameter value is contained in the
one-minute file. This option avoids the unnecessary parsing time that would be needed
if IPDB filters were not used.
Remote Event Collection
A Remote Collector (RC) collects event source messages in a geographically remote
location within an RSA enVision domain. The RCs accumulate local event messages
for a default period of four hours, storing them in a local IPDB (on the internal disks
of the RC).
Every four hours (or at the pre-configured interval, including every minute, if
necessary), an RC-specific service called the NIC Forwarder Service establishes an
SFTP connection to the WinSSHD Server Service on the site D-SRV and transmits the
accumulated data to the D-SRV. The D-SRV then writes the data out to the site IPDB.
Global
IPDB Filter Index
NIC
Packager
Service
Raw One-
Minute File
(ciscopix
10.239.98.53)
Messages NIC
Collector
Service
Minute, Hourly and
Daily Index Files
Window
s
Summa
ry
IPDB Filter
Variables
Table
Definition
Files
Firewall
Table
The RC includes built-in D-SRV functionality to support real-time alerting functions.
An administrator may configure an alert for the RC (using the Administration GUI on
the site D-SRV). When the RC detects the alert conditions, it sends the alert state
immediately to the site D-SRV for analysis there.
Factors Affecting Event Collection
This section describes the general effects of factors such as protocol type, event source
number, and event source types on event collection.
Impact of Push or Pull Protocol
Event collection protocols are either push or pull based. Push protocols send events to
the RSA enVision collection process. Event sources that use push protocols require
very little enVision processing to deliver events to the collection process. Examples of
push protocols are syslog, UDP, TCP, and SNMP.
Pull protocols require the enVision system to connect with the event source in a
defined manner and pull the event information from the event source directly to the
collection process. In addition, pull protocols often require the enVision system to
transform event messages from specific vendor protocol structures to a normalized
event structure. Examples of pull protocols are agentless Windows, Check Point LEA,
ODBC, and File Reader.
Effect of Device Type
Device types vary in their event structure, complexity, length of data, and values
contained in the data. These factors help determine the amount of processing required
to identify and process the events. The length of the data has a direct impact on both
network I/O to collect the event and on disk I/O to store the event. The values in the
data can greatly affect the amount of additional summary information that is obtained
for an event source.
Effect of Multiple Event Sources with the Same IP Address
A single IP address can support more than one event source from which a single
Collector collects and processes events. During processing, each event from the event
sources must be identified to determine the device type so that the events can be sorted
into unique sets of one-minute files. This additional identification step increases the
processing resources and memory required by the NIC Collector Service.
Effect of the Number of Different Device Types
For each unique device type collected and processed, one or more instances of that
event parsing information (a Device XML file) reside in memory to handle the NIC
Packager Service parallel processes that identify and store events. These instances
increases the memory required by the Packager processes.
Effect of the Number of Event Sources
For each event source from which the RSA enVision system collects, processes, and
stores events, memory is allocated to buffer the event source data, CPU resources are
required to process the data, and disk I/O is required to write the data.
For event sources that do not generate events to process every minute, the resources
used are greatly reduced. These event sources use batch transfer protocols, such as
agentless Windows and File Reader. The number of event sources has a direct
relationship to system performance and, therefore, is used as a rough gauge to estimate
system loading.
Effect of the EPS Rate
Collecting, processing, and storing each event requires overhead. As the EPS
increases, this overhead also increases. The EPS rate has a direct relationship to the
amount of disk storage required for a system and provides an additional gauge to
estimate system loading at higher EPS rates.
Effect of the EPS Rate per Event Source
For an event source that has a very low EPS rate, for example, 1 to 200 events in a
one-minute time frame, almost all of the resource cost is fixed in the processing and
disk I/O associated with the individual event source. As the EPS increases beyond this
point, the RSA enVision system must perform additional processing, which requires
additional memory usage and disk I/O.
Effect of Single Site Configuration
Each Collector appliance works independently of the other appliances, with the
exception of sharing the NAS storage device that stores and reads the event data. The
shared NAS can be the limiting factor for a site, although the limitation can be offset
by increasing the performance of the NAS. The NAS is also the common factor
between the collection and analysis components of the site, so either one can affect the
performance of the other.
4: Alerting 43
4 Alerting
Alerting topics describe the components involved in alerting and the flow of event
data through these components. Data structures that group related event sources and
event messages for scalable handling of these resources are described, followed by
factors and conditions that affect alerting operations.
Alerting Components
Alerting Data Flow
Event Source and Event Message Classification
Factors that Affect Execution of Alerting
Alerting Components
The following figure shows the components involved in alerting.
Al erti ng Components
NIC Logger
Service
IPDB
NIC Web
Server
Service
Web UI
NIC Alerter
Service
NIC
Packager
Service
(supporti ng al l servi ces )
NIC Database
Synchronization with nic.db databases
on other nodes in the NIC domain.
Replication
Server and Client
NIC
Database
Server
Service
NIC Server
Service
Event Explorer
44 4: Alerting
Web UI
The web UI provides several tools for managing alert views and receiving alerts.
Tools in the Alerts module include Alert Configuration used to manage alert views,
output actions and correlation rules, Enterprise Dashboard for monitoring the peak
status information of multiple views concurrently from a single screen, and Real-Time
Detail for visually monitoring alerts in the incoming events for available views.
Alert History, which displays past alert data from the IPDB, is described in Reporting
Data Flow on page 53 and IPDB Directory Structure on page 57.
NIC Web Server Service
The NIC Web Server Service handles the creation of and changes to views, correlation
rules, and watchlists, making the appropriate calls to store new and changed data in
the NIC database (nic.db). The service also receives view updates, making these
available to the browser.
NIC Alerter Service
The NIC Alerter Service loads and manages all of the views that are running on the
RSA enVision system. The service passes event requests defined within running views
to the NIC Server Service, which constantly looks for these event messages in the
IPDB. The NIC Server Service returns event messages meeting the search criteria to
the NIC Alerter Service.
The NIC Alerter Service analyzes event information received from the NIC Server
Service to determine whether to generate an alert. If watchlists are configured for the
alert or rule, the service scans the watchlist for input criteria. If VAM is configured for
an alert or rule, the service processes that information to determine the appropriate
confidence level for the alert. A high confidence level influences the service to display
the alert. A low confidence level influences the service to suppress the alert.
The NIC Alerter Service sends alerts to the configured output action, such as an e-mail
(SMTP), a text message, or a ticketing system.
NIC Server Service
The NIC Server Service responds to requests for data by returning data that is stored
in the IPDB. A site could include multiple (up to four) NIC Server Services, one per
D-SRV. If multiple sites exist, the NIC Server Service communicates with NIC Server
Services on those other sites to satisfy data requests.
NIC Database Server Service
The NIC Database Server Service maintains all of the alert view criteria including
watchlists and correlation rules and most of the RSA enVision configuration,
including user accounts, access permissions, and event source configuration. The
service also contains the asset database and vulnerability data. The service runs on
every node and automatically replicates data stored in the NIC Database. The service
uses the nic.db Sybase database as a repository.
4: Alerting 45
NIC Logger Service
The NIC Logger Service collects internal events generated by the RSA enVision
system components including alerts generated by the NIC Alerter Service. The NIC
Logger Service exists on the single appliance or, in multiple appliance sites, on the
D-SRV and RC nodes. The NIC Logger Service is similar to the NIC Collector
Service, except that this service is dedicated to collecting NIC system events for a
single or multiple appliance site.
The NIC Logger Service stores data in one-minute files (files generated once each
minute containing NIC event data accumulated in the one-minute interval) for
processing by the NIC Packager Service.
NIC Packager Service
The NIC Packager Service processes the one-minute files passed from the NIC
Collector Service and the NIC Logger Service. The processing includes reading the
files and creating an index file that optimizes and facilitates access to the messages in
the one-minute file by event ID. Additionally, the service creates summary files that
contain counts and accumulated data from the messages. Finally, the service
compresses the three types of files and stores them in five daily archives in the Internet
Protocol Database (IPDB).
On the D-SRV node, the NIC Packager Service is dedicated to packaging the NIC
system events. On a single appliance site or an RC node, the same NIC Packager
Service packages events from event sources and events from the RSA enVision
system.
46 4: Alerting
Alerting Data Flow
The following figure shows the alerting data flow.
The following actions correspond to the numbered callouts in the preceding figure:
1. Create alert view:
a. An administrator creates the view using a browser to interact with the NIC
Web Server Service.
b. The NIC Web Server Service stores administrator-defined event sources,
messages, correlation rules, and other view criteria in the NIC database
(nic.db).
c. The NIC Database Server Service stores view criteria. In a multiple site
deployment (NIC domain), the replication server and client synchronize the
view with other sites in the NIC domain.
2. The NIC Alerter Service loads the alert view (the view criteria) into memory.
a. The service loads the vulnerability and asset management (VAM) data from
the NIC database into memory. This table is potentially very large and is
loaded only once for an A-SRV. The table is shared by all running views and
is refreshed at five-minute intervals by default with changed or new rows.
Al erti ng
NIC Logger
Service
IPDB
NIC Web
Server
Service
NIC Alerter
Service
NIC
Packager
Service
IPDB
NIC
Server
Service
IPDB
NIC
Server
Service
IPDB
NIC
Server
Service
Multiple Site Only
8
11
\tmp\nuggets
NIC Database
Synchronization with nic .db databases
on other nodes in the NIC domain.
Replication
Server and Client
E-mail, Instant Messages
Text messages,
instant messages
9
1b
10
1a
7
3
4
6
5
6
5
15
13
12
RSA enVision
web UI
NIC Database
Server Service
1c
15
NIC Server
Service 2b
14
2a
4: Alerting 47
b. If device group resolution is needed to determine which event sources are in a
device group, the NIC Alerter Service notifies the NIC Web Server Service
using an HTTPS request. The NIC Web Server Service carries out the
request.
3. The NIC Alerter Service requests events by event source, event ID, and other
criteria.
4. The NIC Server Service resolves event source location by interacting with the
NIC Database Server Service. This returns the directory, and, in a NIC domain,
the node where the event resides. The NIC Server Service resolves event source
locations by reading the site directory (.dir file) maintained by the NIC Locator
Service.
5. The NIC Server Service requests events from the local or remote IPDB.
6. The NIC Server Service reads events from the local or remote IPDB.
7. The NIC Server Service returns matching events to the NIC Alerter Service for
processing.
8. The NIC Alerter Service parses and processes returned events for an active alert
view or correlation rule, evaluating any filter or threshold condition configured for
the messages.
If a watchlist is configured in the alert view, the NIC Alerter Service reads and
processes the watchlist against the messages returned by the NIC Server Service.
If vulnerability and asset management (VAM) information is configured in the
alert view, the NIC Alerter Service processes available VAM data to set the
confidence level of the alert.
The NIC Alerter Service suppresses or triggers the alert as appropriate.
Note: The alerter polls the NIC database every 30 seconds for any configuration
changes and updates its structures accordingly. For any view start or stop operations,
the alerter notifies the NIC database. Updates to the NIC database propagate to other
sites in a multisite environment.
9. When the NIC Alerter Service triggers an alert, it also generates a NIC message,
ID 919010, which contains information about the view, rule, and other conditions
that triggered the alert. The NIC message is passed to the NIC Logger Service for
eventual dispatch to the IPDB.
10. The NIC Alerter Service updates the view state every ten seconds on disk at
E:\nic\csd\viewdatacache with view configuration information.
11. The NIC Logger Services stores collected NIC event messages in the
\tmp\nuggets directory in one-minute files.
12. The NIC Packager Service collects alert events, stored in one-minute files, in the
\tmp\nuggets directory.
13. The NIC Packager Service stores the NIC messages in the IPDB.
14. The NIC Alerter Service writes the real-time view information every 10 seconds
in the viewdatacache directory. The NIC Server Service reads the data and
provides it to the NIC Web Server Service.
48 4: Alerting
15. The NIC Alerter Service initiates configured output actions, and, as configured,
the NIC Web Server Service displays the alert information in real time and in the
alert history.
Event Source and Event Message Classification
The RSA enVision system provides two types of metadata for use in focusing alerts
and correlation rules on specific sets or subsets of event sources and event messages.
Device classes divide event sources into the following four classes.
Security
Network
Host
Storage
Device classes are further divided into subclasses. See Device Classes for more
information.
Message categories divide messages into NIC categories, alert categories, and event
categories. See Event Message Categories for more information.
Factors that Affect Execution of Alerting
This section describes alerting options that impact alerting operations.
Threads and the Number of Views
A view is an administrator-defined set of event sources, messages, correlation rules,
and criteria within a single site for which the RSA enVision system issues alerts. An
alert can be triggered by specified IDS messages, events defined in a watchlist, or
conditions defined by a correlation rule.
An enVision single appliance or multiple appliance site supports up to 64 views
enabled concurrently. Each view is allocated a single thread of execution. The NIC
Alerter Service creates a new thread whenever a view is created or restarted. The
thread terminates whenever the view is stopped or is deleted from the enVision
system. The NIC Alerter Service uses threads to associate alerts with their
corresponding views.
The operating system limits the virtual memory assigned to a thread and its view to 4
GB on 64-bit systems and 3 GB on 32-bit systems. This memory limitation may limit
the number or complexity of views that can be running simultaneously on a system.
You can optimize views by doing the following:
Avoid specifying the same device types or the same IP addresses in multiple
views.
Optimize composition of correlation rules.
4: Alerting 49
Device Types
Each device type has event log parsing information (a Device XML file) that defines
the messages for that event source. The Device XML file is loaded into memory for
use in the view when the view starts. These files can be very large, especially for event
sources with many lengthy event messages. You can optimize resource consumption
by not specifying the same device type in multiple views.
Correlation Rule Complexity
Correlation rules can be complex. For example, a rule could specify that 10 specific
event messages must occur within any sixty-second sliding window of time while no
event messages of another specified type are received. The rule can be extended with
filters looking for specific data within message strings. VAM inputs can also be
factored into a decision to fire an alert.
Rules consist of circuits, statements, and logical operators, and the NIC Alerter
Service limits the number of rules that the RSA enVision system can handle.
Extremely complex rules with numerous logical operators can cause a stack overflow
type of error for the NIC Alerter Service.
Watchlists
Memory used for each view increases as you increase the number of watchlists or
watchlist entries. The speed of processing view data depends upon the number of
regular expression case sensitive evaluations of watchlist entries made. More
evaluations add to the processing time.
Cached Variables, Decay Time, and Multithreading for Variables
The memory required by a view depends upon the composition of correlation rules in
the view. The more cached variables, decay times, and multithreading for variables
that you use in a correlation rule, the more memory the rule uses.
Cached variables are variables, for example, a value in a payload, used in a statement
that you save to compare to variables in another statement. You can use cache
variables when you filter a correlation statement.
Decay time is a time window assigned to a rule. An alert is fired only when all
conditions for a rule are satisfied within the specified time window.
Specifying multithreading for variables in a correlation rule sets the RSA enVision
system to maintain the state for a set of variables across the correlation analysis. To
support a rule using multithreaded variables, the NIC Alerter Service allocates a pool
of memory for each unique multithreading key value coming in. Pools may be
allocated up to the multithreading limit configured in the rule. Any inactive pools
(whose alert has fired or whose decay time has expired), are available and can be
reused.
If you configure rules to use multithreading, factor in the availability of pools of
memory when defining appropriate decay times. Otherwise, memory pools may be
allocated unnecessarily, resulting in memory inefficiency.
50 4: Alerting
Output Action
Output actions send alerts to various channels, including SNMP traps, instant
messages, e-mail messages (SMTP), cell phones or pagers (SNPP), and task triage. If
many output actions are triggered simultaneously, alerting performance can be
impacted. The task triage output action is synchronous and must return before
subsequent actions can begin. Performance is impacted if the A-SRV becomes
unavailable or does not return from the task triage action in a reasonable time.
A Run command is also a slow output action because new processes are created each
time the command is called.
Vulnerability and Asset Management
As the number of assets in the asset database increases, the NIC Alerter Service
requires more memory to load the database information for all the assets in the site or
domain into memory.
5: Reporting 51
5 Reporting
This chapter describes the components involved in reporting and describes the flow of
event data through these components. This chapter also describes report tables and the
importance of event identifiers and metadata for creating meaningful reports.
Reporting Components
The following figure shows the components involved in reporting.
Web UI
The web UI provides several tools for retrieving data of interest and specifying how to
present that data. Tools include query (a tool in the Analysis module), ad hoc reports
(a tool in the Reports module), and alert history (a tool in the Alerts module). In
addition, you can schedule reports to run at a future time.
Reporting Components
IPDB
NIC
Server
Service
IPDB
NIC
Server
Service
NIC
Scheduler
Service
NIC Web
Server
Service
Temporary
Table Report
Database
NIC DB
Report
Server
Service
Web UI
report.db
on other nodes in the domain.
Replication
Server and Client
NIC Database
NIC
Database
Server
Service
nic.db
IPDB
NIC
Server
Service
Multiple Site Only
IPDB
NIC Server
Service
NIC Server
Service
NIC Server
Service
Multiple NIC Servers
(RSA enVision 4.1)
52 5: Reporting
NIC Web Server Service
The NIC Web Server Service processes requests entered using the webUI along with
requests based on scheduled report tasks. The NIC Web Server Service makes the
appropriate calls to obtain the data through the NIC Server Service and, in turn,
formats those results based on the specified report output parameters. Possible outputs
include HTML, PDF, CSV, and, for graphical reports, PNG file formats. In addition,
you can request that the RSA enVision system e-mail the reports or links to the reports
if, for example, the file is too large for your viewing device or you want to be notified
when a report completes.
NIC Server Service
The NIC Server Service responds to requests for data by returning data that is stored
in the IPDB. If multiple sites exist, the NIC Server Service communicates with NIC
Server Services on those other sites to satisfy the data request.
When multiple NIC Server Services are deployed (an option for the RSA enVision 4.1
platform), a load balancing function built in to the NIC Server Service dispatches
report and query requests across the other NIC Server Services as appropriate. For
more information, see Multiple Database Servers in a Site.
Data extracted from the IPDB must be prepared for insertion into an SQL database
(report.db) for further analysis. The parser built in to the NIC Server Service converts
the event into a comma-separated value (CSV) string that contains data about the
event, such as the event source IP address and time stamp, and the event data itself.
The parser uses the Device XML file, a definition file that maps event source
messages so that the parser can extract the relevant message fields. The parser scans
the event to determine if it matches the preprocessor filter. If so, the parser adds the
event to the CSV file. The file is, in turn, used to load data into the temporary report
database table.
NIC Database Server Service
The NIC Database Server Service maintains most of the RSA enVision system
configuration along with the asset database and vulnerability data. In a multiple site
deployment, the NIC Database Server Service provides configuration management for
remote services from any system. The service also helps locate event messages stored
at other sites. The service uses the nic.db Sybase database as a repository.
NIC DB Report Server Service
The NIC DB Report Server Service runs on every A-SRV in a multiple appliance site
or on the RSA enVision appliance in a single appliance site and uses the report.db
database as its repository. The database temporarily holds report data retrieved from
the IPDB for access by the NIC Web Server Service for further analysis (filtering,
sorting, and aggregating of data for reports).
To avoid performance and maintainability issues, the enVision system deletes
temporary data from the report database after the NIC Web Server Service dispatches
the report information, but the disk space allocation persists. The NIC DB Report
Server Service automatically re-creates the report.db database whenever the NIC Web
Server Service is restarted to ensure that the report.db does not keep growing until it
exceeds the capacity of the disk.
5: Reporting 53
NIC Scheduler Service
The NIC Scheduler Service runs preconfigured tasks at specified intervals. These
tasks include system-related work efforts, such as disk usage monitoring and log
directory cleanup, user-defined tasks, and the running of predefined report definitions.
You can configure scheduled reports to run with specified parameter settings, such as
device groups to be scanned, time range, and display options. The NIC Scheduler
Service reads its parameters from the NIC Database Server Service.
Reporting Data Flow
The following figure shows the reporting data flow.
The following interactions correspond to the numbers in the preceding figure:
1. Reporting is triggered in the appropriate way to address the data retrieval needs:
a. You may need immediate access to report data in a tabular or graphic
presentation or you may need to issue a query.
b. You may need to view recent alerts through the Alert History tool.
Web UI
Reporti ng Fl ow
IPDB
Alert history
Temporary
Table Report
Database
report .db
E-mail
NIC DB
Report
Server
Service
Ad hoc report
or query
Scheduled report
calendar (view only)
PDF
Scheduled
reports
3a
6
7a
7b
7c
1a
1b
1c
7d
7e
5b
5a
IPDB
NIC
Server
Service
IPDB
NIC
Server
Service
IPDB
NIC
Server
Service
Multiple Site Only
3b
NIC
Scheduler
Service
on other nodes in the domain.
Replication
Server and Client
NIC Database
NIC
Database
Server
Service
nic.db
SQL Filter
(RSA enVision 4.1)
Parser
NIC Server
Service
NIC Server
Service
NIC Server
Service
Multiple NIC Servers
(RSA enVision 4.1)
4b 4a
2
NIC Web
Server
Service
54 5: Reporting
c. Based on scheduled report task definitions, the NIC Scheduler Service may
trigger a report request to produce a report for future use. The NIC Scheduler
Service reads its parameters from the NIC Database Server Service.
2. The NIC Web Server Service gathers criteria that define the data to be retrieved
and how the data is to be presented (including which temporary report table to
use), and passes these parameters to the NIC Server Service.
If multiple NIC Server Services are deployed, a load balancing function in the
NIC Server Service dispatches the report or query parameters as appropriate
across the one or more available NIC Servers depending on the associated work
load size of the report or query.
In an enVision 4.1 system, the NIC Server Service checks the IPDB filter and
other indices to determine the presence of specific parameter values. In enVision
4.0 and earlier systems, the NIC Server Service decompresses and reads the
individual event messages to search for the specific parameter values. For more
information, see IPDB Filter Index Calculation and Use.
3. Based on a subset of the retrieval parameters, the NIC Server Service does one of
the following operations:
a. In a local deployment, the NIC Server Service retrieves the defined dataset
from the IPDB.
b. In a multiple site deployment, the NIC Server Service communicates with all
other NIC Server Services to access data that resides on other sites. The NIC
Database Server Service helps to locate the other sites.
4. The NIC Server Service processes the dataset as follows:
a. The NIC Server Service parses the retrieved dataset. If the report request
contains an optional preprocessor filter, each event is filtered. If the request
matches the filter, the event string is further processed based on the event
definition found in the corresponding Device XML file. This event string is
parsed into individual fields.
b. In an enVision 4.1 system an SQL filter (a where clause) may be applied by
the NIC Server Service to limit the amount of data that is transferred to the
temporary report database (see diagram action 5).
5. The parsed event is inserted into the report.db temporary report database:
a. For performance reasons, parsed events are first stored in a CSV file and
periodically loaded into a temporary table, which is deleted when the retrieval
completes.
b. Based on additional retrieval parameters (such as additional selection criteria
that could not be used as part of the preprocess filter, requested aggregation
functions, and the sort definition), the NIC Web Server Service passes
retrieval parameters to the NIC DB Report Server Service to perform the
retrieval.
6. When it detects that the data is available in the report.db, the NIC Web Server
Service makes an SQL request to pull the processed data.
7. Depending on who made the request and what presentation parameters were
defined, the NIC Web Server Service further processes the data to satisfy those
requests:
5: Reporting 55
a. The NIC Web Server Service formats the ad hoc report or query results using
HTML and returns the results to the web UI user.
b. The alert history presents the data and allows you to examine individual alerts
for details.
c. The NIC Web Server Service formats the results as HTML or PNG files and
updates the calendar interface to allow easy access to these reports from the
Scheduled Report panel.
d. The NIC Web Server Service formats report data into PDF files that match as
close as possible the format of the HTML report. Alternatively, users may
request data to be returned as a .CSV file for use by an external application.
Note this CSV file differs from the CSV report data stored the temporary
report database.
e. HTML, PNG, and PDF reports can be e-mailed.
Reporting Tables
Reports and query results are formatted for viewing using temporary report database
tables. The tables are populated by using a parsing algorithm that analyzes specified
events against corresponding event descriptions found in the device xml files.
The RSA enVision system provides a variety of report tables. Each report table is
designed to display event content from specific messages from specific event sources.
Each event source has associated device files that specify for each message, the table
to use for that message. An event source typically has sets of messages that parse to
different report tables. For example, a firewall has messages for the Firewall report
table but other messages use the Firewall Blocked URL table that handles messages
related to blocked URL and FTP access attempts. Still other messages use the Firewall
Email Security table that handles messages related to potential security breaches
strictly dealing with e-mail.
A report table may be populated by data from multiple event sources. For example, the
Firewall report table may have event data from a Checkpoint FireWall-1, a CiscoPix
Firewall, and a SonicWALL Firewall, depending on which event sources are defined
in the report criteria.
The enVision system provides a Global table that supports fields common to many
different event source types. Event messages from most event source types have
message variables that map to DestinationAddress, SourceAddress, UserName, and so
on. Use the Global table when reporting on event messages from very different types
of event sources such as from firewalls, applications servers, and storage systems.
Summary tables are also provided to support reports using summary information in
the IPDB.
ESUs received after J uly 22, 2010 provide report tables that are redesigned to
accommodate the ever-increasing number of supported event sources. Some older
tables have been reorganized or combined with other tables and some new tables are
provided. For example, the Universal table is a new table intended to eventually
replace the global table.
56 5: Reporting
The following figure shows how the device files map individual event messages to the
appropriate report table.
When determining which table to use for specific messages, use the Manage Messages
to Parse function in the GUI. This function scans the device files and returns a screen
showing the message to table mapping for each individual message as shown in the
following example.
IPDB
File System
Check Point FireWall-1
Messages:
CiscoPix Firewall
Messages :
Device Files
Firewall
Temporary
Report Tables
Check
Point Audit
Logs
Intrusion
VPN
Check
Poi nt
Ci scoPi x
Event Messages
5: Reporting 57
Report Table Fields
Report tables are templates with many fields that can be populated with data from the
supported event messages for a table.
Selecting a report table from the GUI Select table drop-down list determines the list
of fields that appears in the Select fields multi-select list box. Three kinds of fields
appear in the Select fields multi-select list box:
Fields extracted directly from message events. Examples of these fields are
LogonID, IPMask, and DestinationPort.
Aggregated fields based on fields extracted from message event. These fields
operate on message event fields. Examples of aggregated fields are
count(GroupID), and percentCount(DestinationHostID).
Derived fields based on where the event was generated. For example, the device
ipaddr of the device that generated the message.
Users can view the mapping between message variables and report columns by using
the Manage Variables screens.
Factors That Impact enVision Reporting
This section describes the factors that impact reporting operations.
IPDB Directory Structure
Event messages and the summaries and indexes from those messages are stored in the
Internet Protocol Database (IPDB) file system in the directories shown in the
following figure.
Because the directory structure is organized by event source IP address, and time, you
can use these two parameters to control how many files are accessed. How you specify
these parameters depends on how you invoke the report:
Time range:
IPDB
\envi si on
\l snode
\data
\col l ector name
\ devi ce type
\ IPaddr
\ yyyy
\ mm
\ dd
1440/day
Event Files
*.dat
Index Files
*.idw
Summary Files
*.sdw
Index Summary
*.isw
Summary Summary
*.ssw
1440/day
1440/day
24/day
24/day
Di rectory Structure
Saved Fi l es
58 5: Reporting
For a scheduled report task, ad hoc report, or query, you can specify a
customized time range or a relative time range (relative to either the current
time or the last whole hour, day, week, or month) depending on the request.
To display information in Alert History, the RSA enVision system maintains a
marker in the nic.db (NIC database), stamped with a date and time. NIC
Alerts that occur later than the time stamp on the marker are available in the
Alert History tool. Periodically, the enVision system re-synchronizes the
alerts. This re-synchronization updates the date and time on the marker, so
that only the more recent alerts are displayed.
If you disable NIC Alerter Service resynchronization or set resynchronization
to occur after a very high number of alerts, an unexpected or unnecessarily
large amount of data may be returned, which could impact Alert History
performance. By default, Alert History uses the time stamp marker to
determine the time range of the retrieval. However, you can override the time
stamp marker by specifying a time frame, such as the last day or last hour.
IP addresses:
The enVision system accepts event source criteria or device groups to specify
event sources to be included in a report or query. The system resolves these
criteria to a list of event source IP addresses and passes that list to the IPDB.
Event source criteria specify limited criteria, such as the IP address or device
type (see Device Type), to determine from which event sources retrieval
occurs. Most reports supplied with the enVision system use event source
criteria to determine which event sources are included in a report.
Device groups (see Device Groups) can be more specific than event source
criteria because device groups can specify more attributes than can be
specified using event source criteria alone. Device groups can specify
attributes or combinations of attributes such as device class and subclass (see
Device Classes), device type, location, physical attributes, and importance
within the organization (see Device Attributes).
The Alert History relies on standard A-SRV hostnames in the form of
hostname-AS#, for example, SIEM-AS1, to limit lookups to specific NIC
nodes. If you use this naming convention for A-SRV hostnames, you avoid
unnecessary lookups that involve all NIC nodes. If you do not use this naming
convention, the Alert History searches all NIC nodes for alert data.
Indexed Event IDs
While IP address and time range limit which files are accessed, equally important are
the indexed fields of event IDs. The RSA enVision system maintains index files,
which enable faster, more efficient retrieval of data based on these event IDs.
Typically, you create a report by first selecting a table. This table provides a template
for returning the data that is extracted from each retrieved event.
The enVision system uses the Device XML files to determine how to map individual
values in an event to the fields in a table. Every event definition in a Device XML file
has an associated table ID. The enVision system uses that association to retrieve only
those event IDs that can populate that table.
5: Reporting 59
Indexing by message ID further enhances performance. You can limit the query to
only scan relevant event IDs. The enVision system automatically limits event IDs
based on the table selected or, if the Global table is selected, based on the fields
selected.
To limit which message IDs are scanned, you can turn off the parse flag for
specific events that queries are never to scan.
To further specify which message IDs to consider, you can add those message IDs
to the where clause of the report specification (a where clause is an SQL statement
that further narrows a dataset).
If the Global table has been specified, further criteria specifying the event category
(see Event Message Categories) determines which message IDs to scan (that is, use
all event IDs associated with that event (message) category, limited by device type). In
report where clauses use the ten digit Category ID to specify the message category.
IPDB Filters
RSA enVision 4.1 uses IPDB filter indices to improve searches of the IPDB. IPDB
Filter Index Calculation and Use describes how indices are inserted into IPDB index
files.
Without IPDB filters, the NIC server service always searches the relevant one-minute
file in the IPDB, parsing all contained messages for target parameter values. IPDB
filters let the NIC Server Service just check the filter index to determine whether the
target parameter value is contained in the one-minute file. This option avoids the
additional parsing time that would be needed if IPDB filters were not used.
DNS Resolution
IP addresses in reports can be resolved to hostnames. This operation relies on your
network DNS system to resolve each IP address included in a report. Avoid using
DNS resolution for very large reports containing thousands of IP addresses as this
interaction with DNS can add a long time to report generation and can impact network
bandwidth.
Summary Data
Beyond specifying the IP address, time range, and message IDs (either explicitly in
the where clause or implicitly with table selection), you can further optimize how a
report runs by selecting a summary table rather than a detail table if you are only
interested in summarized data.
As events are being packaged, the NIC Packager Service summarizes the data based
on the Device XML file summary rules for each message. For each event source,
summarized counts are held for various values, such as ipaddr and username. A
request to retrieve against a summary table uses the time range and event source list to
restrict how much summarized data is brought forward to the temporary table report
database for further filtering.
60 5: Reporting
SQL Filters
To improve the overall performance of reporting, you should limit the amount of data
as early in the flow as possible. You can use preprocess filtering to filter the data
before it reaches the temporary report database. Several factors determine whether or
how much preprocess filtering takes place:
When running a report either ad hoc or through the scheduler, you can select the
appropriate preprocess filtering for the report. For queries, you can enable the
preprocessor.
You can specify criteria in a simple form that the RSA enVision system can
convert into a regular expression without altering or removing valid events. For
example, username ='fred' or username ='wilma' can be reduced to a regular
expression fred|wilma. However, username ='fred' or username !='wilma' is a
more complicated form that the enVision system rejects for preprocessing.
The parser applies criteria to the entire CSV message string that results from message
parsing. Therefore, the filtering may give false positives and return more events than
are being requested. For example, in a string 1.2.3.4, fred, 2.3.4.5, the values parse
into the following fields:
Saddr =1.2.3.4
Username =fred
Daddr =2.3.4.5
If you specify the criteria Where saddr =2.3.4.5, this event is still brought from the
IPDB into the temporary report database for processing, even though the event is
filtered out of your report
Additional Where Clause Filtering in RSA enVision 4.1 Systems
The RSA enVision 4.1 system also provides an additional where clause filtering that
users can apply to data before it is transferred to the temporary report database. This
function improves performance by avoiding transfer of unnecessary data to the
temporary report database.
6: Vulnerability and Asset Management 61
6 Vulnerability and Asset Management
This chapter describes the components involved in Vulnerability and Asset
Management (VAM) and describes the flow of event data through these components.
Asset data defines each asset, specifying information such as operating system, ports,
and services. The RSA enVision system uses this information with vulnerability data
from the National Vulnerability Database to determine the confidence level for
generating alerts for received IDS messages.
Vulnerability and Asset Management Components
The following figure shows the components involved in vulnerability and asset
management.
VAM Components
NIC Asset
Collector Service
QualysGuard
Scanner
McAfee / IBM
ISS Scanners
Nessus /
nCircle
Scanners
NIC Asset
Processor Service
Nessus /
nCircle
Qualys-
Guard
McAfee /
IBM ISS
Vulnerability
Knowledge
Database
mast er_vam.db
DLL
DLL
DLL
VAM
Update
NVDB
National
Vulnerability
Database
Synchronization with NIC databases on
other nodes in the domain.
Replication
Server and Client
NIC
Database
Server
Service
Configuration
Database
NIC Dat abase
Event Source
Update
(Contained in the
Configuration
Database )
62 6: Vulnerability and Asset Management
NIC Asset Collector Service
This service collects all asset information from each of the five supported asset
scanners and from the third party asset input feature. The NIC Asset Collector Service
passes the data as an XML asset scan file to a temporary folder in the Configuration
database for consumption by the NIC Asset Processor Service.
The NIC Asset Collector Service contains DLLs that interface to the supported asset
scanners to receive asset data provided in proprietary formats. The RSA enVision
system uses a polling protocol to retrieve asset data from McAfee and IBM ISS
scanners. The enVision system uses a passive listening protocol to receive asset data
from the Nessus, nCircle, and QualysGuard scanners.
NIC Asset Processor Service
This service parses all of the raw asset scan files from the temporary folder in the
Configuration database and outputs normalized asset fingerprint (AFP) files that are
consumable by the RSA enVision system. AFP files are stored in the Configuration
database. Malformed or unreadable asset scan files are rejected.
Each AFP file specifies the features of one asset and known potential vulnerabilities
based on the Common Vulnerability Enumeration (CVE) vulnerabilities defined in the
National Vulnerability Database.
The NIC Asset Processor Service assists in alert handling. When the enVision system
receives IDS messages referencing an asset, the NIC Alerter Service requests that
assets vulnerability and AFP information. The NIC Asset Processor Service analyzes
the data to determine a confidence level to help the NIC Alerter Service determine
whether to fire or suppress the alert.
Configuration Database
The Configuration database retains the raw asset scans in a temporary folder until the
NIC Asset Processor Service processes the scans.
The database also maintains a table called the production VAM table, which contains
normalized AFP files and other asset information.
In a multiple site deployment, the Configuration database synchronizes the production
VAM table across all sites.
Vulnerability Knowledge Database
The Vulnerability Knowledge Database (VDB) is an embedded repository of
vulnerability information. The VDB is derived from the National Vulnerability
Database of the U. S. Department of Homeland Security. The National Vulnerability
Database integrates all vulnerability data from publicly available resources as
Common Vulnerability Enumeration (CVE) vulnerabilities. The National
Vulnerability Database contains detailed descriptions of each current vulnerability,
including potential impact, the type of loss that a vulnerability can cause, and an
indication of how the attack can result in a confidentiality breach.
The RSA enVision VAM & Signature Content Update process ensures that the
enVision platform has the latest changes from the National Vulnerability Database.
For information about updates, see the enVision Help topic Update enVision VAM &
Signature Content.
Vulnerability and Asset Management Data Flow
The following figure shows data flow during asset collection and alert conditions.
VAM Components
NIC Asset
Collector Service
(supporting all services)
Synchronization with NIC Database
and Production VAM tables on
other nodes in the site or domain.
QualysGuard
Scanner
McAfee / IBM
ISS Scanners
Nessus /
nCircle
Scanners
Configuration
Database
NIC Dat abase
NIC Asset
Processor Service
Nessus /
nCircle
Qualys-
Guard
McAfee /
IBM ISS
Vulnerability
Knowledge
Database
mast er_vam.db
Asset scans (native
scanner formats )
AFP
Normalized
AFP files
Production
asset data
DLL
DLL
DLL
VAM
Update
NVD
National
Vulnerability
Database
IDS Message ID
CVE, VID
Replication
Server and Client
NIC Alerter
Service
NIC Database
Server Service
1
6
7
4
Asset | Bi tmask | AFP | Scope | IPAddr | ...
Producti on VAM Tabl e
5
3
Confirmed-
vulnerability mask
Not-applicable-
vulnerability mask
Found-
feature mask
Bi tmask (32 Kb)
8
Event Source
Update
2
VIDX
VAM
XML
Asset
Scan
Asset
Scan
(Contained in the
Configuration
Database)
The following interactions correspond to the numbered callouts in the preceding
figure.
1. VAM updates install new vulnerability data and new IDS device XML files in the
VDB.
2. Event Source Updates provide new and changed VAM XML files, and
VIDX(vulnerability index) values for supported event sources. RSA determines
VIDX values, which map specific event messages to relevant Vulnerability ID
(VID) values that are assigned by the National Vulnerability Database (NVD).
3. Asset scanners feed their asset scans (native xml files) to the NIC Asset Collector
Service which passes these to the NIC Asset Processor Service.
4. The NIC VA Processor Service normalizes the asset scans by querying the VDB
vulnerability data and scanner translation tables to convert the raw scan data to
normalized data and an AFP file format that the RSA enVision system can use.
5. For each asset included in a scan, the NIC Asset Processor Service stores the
normalized data (production asset data) and the AFP files in the Production VAM
table in the Configuration database.
The Production VAM Table includes for each asset:
Asset identifier (the IP address of the asset)
Bitmask (32K in length) containing:
Found-Feature Mask, calculated from the list of features contained in the
asset scan
Confirmed-Vulnerability Mask, obtained by setting bits for confirmed
vulnerabilities (found features and relevant vulnerabilities)
Not-Applicable-Vulnerability Mask, obtained by setting bits for rejected
vulnerabilities (vulnerabilities determined to be not relevant)
VIDX, a vulnerability index calculated from vulnerabilities returned in the
asset scan
AFP file, a complete XML file for the asset, derived from the asset scan
Scope value, indicating the asset location, department, or organization
Numerous other parameters
6. When the NIC Alerter Service starts and starts a view, the NIC Alerter Service
reads the entire Production VAM table into memory. The table is shared by all
views running on the A-SRV.
7. When the NIC Alerter Service detects an IDS message with a VIDX value that
corresponds to a vulnerability, the NIC Alerter Service determines a confidence
level using the logic illustrated in the following figure:
8. The NIC Alerter Service uses the confidence level to suppress or display the alert.
VAM Extensibility
The RSA enVision system stores vulnerability and asset management data as AFP
metadata in the NIC Database. Asset data is gathered by the supported scanners and
consists of the event source type, hardware and operating system version information,
installed software and version information, and hardware and software vulnerability
information.
Users can extend this generic information by adding device attributes such as the
owner (department or organization), system administrator, additional vulnerabilities,
and importance within the organization.
See Device Attributes, for details and uses for device attributes.
Factors that Impact VAM
In a multiple site deployment, the size and number of AFP files stored in the
Production VAM table affect replication time for the Configuration database. For
example, adding a site with many thousands of assets to an existing domain may
require many hours to replicate across the domain.
Does the IDS event have a
vulnerability (a vidx line for this
message in the device XML)?
Is the Source Address or
Destination Address selected
for the confidence filter for this
message?
Is the Source Address or
Destination Address listed in
the Production VAM table?
Do the NVD
vulnerability and Production
VAM table vulnerability
bitmasks match?
Extract vulnerability bitmask
(downloaded from NVD).
Extract asset vulnerability bitmasks
from the Production VAM table.
Perform a bitwise comparison of
the bitmasks.
No
Yes
Yes
Yes
Yes
No
Set confidence
level filter to
high priority
Leave
confidence level
filter at medium
priority (default)
Set confidence
level filter to
low priority
No
No
Leave
confidence level
filter at medium
priority (default)
Leave
confidence level
filter at medium
priority (default)
Number and Size of AFP files
The number of assets directly affects the rate at which new asset data is inserted into
the asset database because operations on very large asset tables take more time to
complete than operations on smaller asset tables.
Size of the VAM Database
The size of the VAM asset database directly affects operations in the web UI when the
tables grow to over 300,000 assets. Avoid extremely large asset tables to stay within
enVision webserver memory limitations for the best Web UI experience.
Index 67
Index
A
alerting components, 43
alerting data flow, 46
alerting, impacts on performance, 4850
C
collection components, 33
collection data flow, 37
collection services, 3437
Customer Support, 9
D
decay time, 49
E
Enhanced Availability configuration, 17
Event Source Integrator, 25
H
help desk, 9
I
IPDB filter, 21, 22, 38, 39
M
multiple appliance site, 13
multiple database servers, 16, 23, 52
multiple site topology, 18
multithreading for variables, 49
N
NIC Alerter Service, 44
NIC Collector Service, 36
NIC Database Server Service, 44, 52
NIC DB Report Server Service, 52
NIC File Reader Service, 34
NIC FW-1 LEA Client Service, 34
NIC Logger Service, 37, 45
NIC ODBC Service, 34
NIC Packager Service, 37, 45
NIC Scheduler Service, 53
NIC SDEE Collection Service, 34
NIC Server Service, 44, 52
NIC SFTP Agent, 36
NIC Trapd Service, 36
NIC VMWare Collection Service, 35
NIC Web Server Service, 44, 52
NIC Windows 2008 Collection Service, 35
NIC Windows Service, 35
NIC WinSSHD Service, 36
O
output actions for views, 50
P
parser, 52
R
remote collectors, 15
reporting components, 51
reporting data flow, 53
reporting, impacts on performance, 5760
S
single appliance site, 11
support, technical, 9
T
technical support, 9
V
VAM components, 61
VAM data flow, 63
VAM, impacts on performance, 65
views and cached variables, 49

Envision Architecture

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

Envision Architecture

Uploaded by

Copyright:

Available Formats

RSA enVi si on Pl atform 4.0 and 4.

You might also like