Envision Architecture

5/26/2018 Envision Architecture

1/67

RSA enVision Platform 4.0 and 4.1

Architecture Guide


2/67

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 trademarksof EMC Corporation in the United States and/or other countries. All other trademarks used herein are the property of theirrespective 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, andmay be used and copied only in accordance with the terms of such license and with the inclusion of the copyright noticebelow. This software and the documentation, and any copies thereof, may not be provided or otherwise made available to anyother person.

No title to or ownership of the software or documentation or any intellectual property rights thereto is hereby transferred. Anyunauthorized 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 tothird-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 encryptiontechnologies, and current use, import, and export regulations should be followed when using, importing or exporting thisproduct.

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 changewithout notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED "AS IS." EMC CORPORATION MAKES NOREPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THISPUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY ORFITNESS FOR A PARTICULAR PURPOSE.
http://www.rsa.com/http://www.rsa.com/legal/trademarks_list.pdfhttp://www.rsa.com/legal/trademarks_list.pdfhttp://www.rsa.com/


3/67

Contents 3

RSA enVision Platform 4.0 and 4.1 Archi tecture Guide

Contents

Preface...................................................................................................................................7About This Guide................................................................................................................ 7RSA enVision Documentation............................................................................................ 7

Related Documentation....................................................................................................... 8

Support and Service ............................................................................................................ 9

Before You Call Customer Support ............................................................................. 9

Chapter 1: RSA enVision Topologies ...............................................................11Single 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...................................................................................................... 15Multiple 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 .................................................................................................................. 27Event 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 ................................................................................... 33Event Collection Components .......................................................................................... 33Collection 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/67

4 Contents


IPDB Filter Index Calculation and Use ..................................................................... 39

Remote Event Collection .................................................................................................. 40

Factors Affecting Event Collection................................................................................... 41

Chapter 4:Alert ing ....................................................................................................... 43Alerting 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 .................................................................................................. 51Reporting 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 ..................................................................................................... 58IPDB 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 ..................................... 61Vulnerability and Asset Management Components.......................................................... 61

NIC Asset Collector Service...................................................................................... 62


5/67

Contents 5


NIC Asset Processor Service ..................................................................................... 62

Configuration Database ............................................................................................. 62

Vulnerability Knowledge Database ........................................................................... 62

Vulnerability and Asset Management Data Flow............................................................. 63VAM Extensibility ............................................................................................................ 65

Factors that Impact VAM ................................................................................................. 65

Number and Size of AFP files ................................................................................... 66

Size of the VAM Database ........................................................................................ 66

Index .....................................................................................................................................67


6/67


7/67

Preface 7


Preface

About This Guide

This guide provides information that you can use to help understand RSA enVisionplatform data flows and operational factors that can affect system performance. Thisguide is for advanced users and assumes detailed knowledge of the enVision platform.

Numbered interactions in the dataflow diagrams imply the general flow of datathrough the system. Some numbered interactions are not prerequisites to subsequentactions, but instead depict alternative flows determined by the specific use case suchas 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 orcapabilities 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 thisrelease, as well as workarounds for known issues. The latest version of the

Release Notesis available on RSA SecurCare Online athttps://knowledge.rsasecurity.com.

Overview Guide.Provides an introduction to RSA enVision platform features andcapabilities.

Hardware Setup and Maintenance Guide.Provides instructions on setting up andmaintaining RSA enVision appliances. Intended audience is the systemadministrator.

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 versionof the RSA enVision platform to the current version.

Virtual Deployment Guide.Provides instructions on installing an RSA enVisionsingle appliance site or Remote Collector on a virtual infrastructure.

Administrators Guide.Provides instructions on the basic setup and maintenanceof the RSA enVision platform. Includes instructions for the most commonadministrator tasks.

Users Guide.Provides information that helps users to get started using theRSA enVision platform. Includes instructions for the most common user tasks.

Backup and Recovery Guide.Provides instructions on backing up anRSA enVision system and recovering from a hardware failure.

Security Configuration Guide.Provides an overview of security configurationsettings in the RSA enVision platform.
https://knowledge.rsasecurity.com/https://knowledge.rsasecurity.com/


8/67

8 Preface


Universal Device Support Guide.Describes how to add log collection andanalysis support for event sources that the RSA enVision platform does notsupport.

RSA enVision Help.Provides comprehensive instructions on setting upRSA enVision processing options and using RSA enVision analysis tools.

RSA continues to assess and improve the documentation. Check RSA SecurCareOnline for the latest documentation.

Related Documentation

For information about the RSA enVision Event Explorer module, see the followingdocumentation:

Release Notes.Provides information about what is new and changed in this

release, as well as workarounds for known issues.Installation Guide.Provides instructions on installing the RSA enVision EventExplorer module on your client machine in separate guides for MicrosoftWindows and Apple Macintosh operating systems. Intended audience is the enduser.

RSA enVision Event Explorer Help.Provides comprehensive instructions onsetting up and using the RSA enVision Event Explorer module.

For information about the RSA enVision EventSource Integrator, see the followingdocumentation:

Release Notes.Provides information about what is new and changed in this

release, as well as workarounds for known issues.Overview Guide.Provides an introduction to RSA enVision EventSourceIntegrator features and capabilities.

RSA enVision EventSource Integrator Help.Provides comprehensiveinstructions on using RSA enVision Event Source Integrator.


9/67

Preface 9


Support and Service

RSA SecurCare Online offers a knowledgebase that contains answers to commonquestions and solutions to known problems. SecureCare Online also offersinformation on new releases, important technical news, and software downloads.

The RSA Secured Partner Solutions Directory provides information about third-partyhardware and software products that have been certified to work with RSA products.The directory includes Implementation Guides with step-by-step instructions andother 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 enVisionsoftware.

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 backof the appliance, or open a Dell Openmanage Server Administrator session,

and click System > Properties > Summaryto find the serial number in thechassis service tag field.

On a virtual appliance, the serial number of the RSA enVision software.

Open the C:\WINDOWS\system32\drivers\etc\Nie-oe.datfile, and locatethe 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
https://knowledge.rsasecurity.com/http://www.rsa.com/supporthttp://www.rsasecured.com/http://www.rsasecured.com/http://www.rsa.com/supporthttps://knowledge.rsasecurity.com/


10/67


11/67

1: RSA enVision Topologies 11


1RSA enVision TopologiesThe RSA enVision platform supports two deployment types and three topologies tosatisfy various collection, reporting, and alerting requirements. Topologies denotewhether 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 theintent of each topology.

Single Appliance Site

A single appliance site is an RSA enVision deployment consisting of one enVisionappliance that provides complete enVision functionalityevent collection, eventstorage, 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 theHardware Guide. For information on configuring a single appliance site, see theConfiguration Guide.

Single Appliance Interfaces and Event Data Flows

Application services (in the A-SRV portion of the system) provides administrativeaccess for managing user access to the system. User account data is maintained in theA-SRV portion of the system. Administrators perform data management tasks, such assetting up directories and disk usage parameters and managing storage locations, inthe D-SRV portion of the system. Administrators also perform collectionmanagement, configuring the system to listen or poll event sources for log messages.

RSA enVision Appliance

External Storage Ap pliance (Opt ional)

RSA enVision Functions

D-SRVCollector

User

A-SRV


12/67

12 1: RSA enVision Topologies


Users interact with the system by accessing the A-SRV to run reports. Reports return tothe 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 forincident 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 wherethey remain available for forensic analysis and reporting. A server in the D-SRV watchesfor any event messages defined in correlation rules, passing the target events to thereal-time alert monitoring function for processing by the correlation logic. If acorrelation rule evaluates to true, the RSA enVision system generates an alert within theAlerting function and sends that alert through configured data outputs to a securityoperator.

RSA enVision

Event Collection (Collector)

Data Distribution (D-SRV)

Application Services (A-SRV)

RSA enVision

dministrators

and Users

Alerts

RSA enVision GUI,

E-Mail, Instant Messages

Text Messages,

Instant Messages

External

TicketingSystem

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 Firewal lsHubs and

Switches

Laptops and

DesktopsAntivirus

ScannersIPS/IDS

AdministrationRSA enVision GUI,

Event Explorer


13/67



Multiple Appl iance Site

A multiple appliance site distributes RSA enVision functionalityevent collection,event storage, administration, and useto three or more separate, purpose-builtappliances. A multiple appliance site can handle a larger number of event sourcesdistributed over a larger physical area than a single appliance site. An enVision 4.1system supports up to four configured Database Servers.

The following figure shows a multiple appliance site deployment.

Multip le Appl iance Interfaces and Event Data Flows

Administrators, users, and security operations personnel using a multiple appliancesite 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. Allevent messages are passed to the event storage and retrieval function where theyremain available for forensic analysis and reporting. Event storage in a multipleappliance configuration is always located in a centralized NAS (network attachedstorage) that is accessed from the D-SRV using a switch (these elements are not shownin the diagram).

Multiple App liance Site

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-SRVCollector

RSA enVision Functions


14/67



A server located in the D-SRV watches for any event messages defined in correlationrules, passing the target events to the alerting function for processing by thecorrelation logic on the appropriate A-SRV. If a correlation rule evaluates to true, theenVision 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, twocollectors, 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 ApplicationServers using the administration component of the A-SRV.

2. Event source listeners receive events sent by event sources. Event source pollersrequest events from event sources using RPC and other client-side methods.

Legend:

Data Distr ibu tion (D-SRV)

Event Storageand Retrieval

Data

Management

Administrative data flows

Event related data flows

Event Collection

Collection

Management

Event Source


Event Sources

LogsLogs

2

3

4

6

Event Collection

Collection

Management

Event Source


Appl ication Servi ces

(A-SRV)

Administration

Appli cation Servi ces

(A-SRV)

Administration

1

AlertsAlerts,

Reports AlertsAlerts,

Reports 5

6

Event Sources

Collector Collector 2

Data OutputsReal-Time

AlertingData Outputs

5

6

Real-Time

Alerting


15/67



3. All events get stored and are accessible by the minute in which they occur, by IPaddress, 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 aredetected.

5. Alerts are passed to Security Analysts interacting with the enVision system usingEvent Explorer (the preferred interface), the Administration GUI, or possibly aticketing application.

Data Output controls pass alerts and queries over preconfigured channels to theusers who need them.

6. Security Analysts can respond to alerts by researching related events maintainedby the enVision system.

Analysts and other users may run queries or reports against past events.

Remote CollectorsA multiple appliance site supports up to 16 Remote Collectors (RCs), which collectlogs in remote locations and forward the logs to the D-SRV. The following figureshows a multiple appliance site that includes two remote locations, each with aRemote Collector. The switch creates a private LAN to interconnect the enVisioncomponents in Location 1. Remote Collectors at Locations 2 and 3 connect to theD-SRV public LAN connection.

Each remote collector has both D-SRV and LC (but not A-SRV) functionality. Thesefunctions 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, theRC 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 topicMultiple Site Deployment.

For information on setting up the hardware for a multiple appliance site, see theHardware Guide. For information on configuring a multiple appliance site, see theConfiguration Guide.

For information on setting up the hardware for a remote collector site, see theHardware Guide.

Location 2

Location 1

Location 3

Remote

Collector

External

Storage

LC

D-SRV

A-SRV

LC

Switch

PrivateLAN

PublicLAN / WAN

Remote

Collector


16/67



Multip le Database Servers in a Site

The RSA enVision 4.1 platform supports configurations with up to four D-SRVappliances in a site. The database server contains the NIC Server Service that

communicates with the external storage (Network Attached Storage) system thatstores event data, asset data, and configuration data. Adding D-SRV appliancesapplies additional NIC Server Services that enable the system to handle more accessrequests for event or configuration data than could be handled by a system with asingle D-SRV.

This design approach gives customers room to grow their systems as their collectionand processing needs expand by providing the following enhancements over a singleD-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 messagesinclude the global session ID which provides the D-SRV name and the type ofdata request.

The following figure shows a configuration with multiple D-SRV appliances.

The application server connects to a local NIC Server Service based on configuredcommunication parameters. A load-balancing function on the D-SRV determineswhich D-SRV node handles the request, redirecting the application server to connectwith that node.

Location 1

ExternalStorage

LC

A-SRV

LC

Switch

PrivateLAN

PublicLAN / WAN

D-SRV

D-SRV

D-SRV

A-SRV

D-SRV


17/67



Enhanced Availability

Planned or unplanned downtime of an RSA enVision appliance can lead to the loss ofcritical 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 inMicrosoft Windows 2003 Enterprise Edition. One or more additional LCs areprovided and configured into the cluster. The cluster role assignment enablesautomatic or manual movement of duties from one appliance to another in the event ofappliance 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 eachLC. The Database Server has a permanently assigned DA1 (Data Appliance) role, so itparticipates in moving LC roles among appliances as needed, tracking changes in thesite 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. TheLC services read their configuration from the Cluster Configuration Table maintainedin the NAS. In environments using ssh to transfer events to a Collector, all clusteredLCs must be identically configured with ssh keys so that they can operate properlyregardless of which CA role they assume.

Local Collectors use virtual IP addressing so that event sources can find them after arole change occurs. Outbound RPC calls (Windows collection) use the static node IP.

EA Cl uster

LAN

Switch

Local Collector

CA2 Role

Local Collector

CA1 Role

ApplicationServer

ApplicationServer

Local Collector (idle)

CA3 Role

Private

Network

External

Storage

NASDatabase ServerDA1 Role

Local Collector

CA4 Role

This Collector does

not currently havethe role of LC

Role


18/67



Security of the Operational Environment

The RSA enVision platform runs on a hardened operating system that minimizesattack opportunities by removing unnecessary programs and services from the system.

The OS also improves reliability and availability through the use of patches andupdates that have been pre-tested by RSA.

The RSA enVision platform is assumed to be configured in its own independentActive Directory domain. This configuration enables the OS to be configured withappropriate access privileges and hardening requirements according to theRSA-specified operational environment.

A switch placed between the enVision appliances and the NAS, enables the NAS to beset 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-levelnetworks with many event sources distributed across a wide (even global) geographicarea. Multiple site deployments consist of two or more multiple appliance sites joinedin a hierarchical master-slave relationship. The following figure shows a simplifiedmultiple site deployment with four sites.

NIC domains follow a tree topology, relying on a master-slave relationship to resolvethe 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 thebranches. 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. Aremote collector site is also a slave to a master site.

Site 3

Collector

Database Server

Application Server

CollectorSite 4

Collector

Database Server

Application Server

Collector

Site 2

Collector

Database Server

Application Server

Collector

Site 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


19/67



This master-slave relationship plays a role in binding together a multi-site deploymentso that event data in one site can be located from other sites in the deployment. SeeData Synchronization in a NIC Domainon page 23for details.

This master-slave relationship also dictates the order in which configuration changesare deployed throughout the NIC domain. Changes to the domain master occur firstfollowed by changes to the slave sites. Along the branches, master sites are alwayschanged before slave sites. This applies to the following operations:

Installation and configuration.

Migration from earlier RSA enVision versions to newer versions, includingsecurity package upgrades.

Event Source Updates (ESUs)


20/67


21/67



2. Collector normalization rules parse and normalize incoming event sourcemessages, 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 eachmessage for each supported event source.

The collector prepends an enVision event ID and timestamp to each message tohelp interpret and collate the normalized events.

The collector also segregates the messages into one-minute files (each filecontains all messages received within a one-minute interval from a single IPaddress). The collector creates index files to speed up processing, adding an IPDBfilter index to the index files. For more information, see IPDB Filter IndexCalculation and Use.

Finally, the collector passes these normalized files to the Internet ProtocolDatabase (IPDB) file system for storage.

3. The NIC Server Service manages the IPDB, which is the enVision repository forboth translated and raw event messages.

The IPDB is the hub of the enVision system, storing all collected event messagesin a file system organized by device, IP address, and time (year\month\day), aswell as maintaining index files to facilitate searches.

Users retrieve event messages by using report templates or by constructingcustom SQL queries.

4. The RSA enVision 4.1 system includes bulk data export providing historical andad hoc data mining to export defined sets of data for external storage or use. ACLI 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 triggeralerts. Users configure alert views and correlation rules through theAdministration GUI. Filters (part of an alert view set through the AdministrationGUI) screen out messages deemed irrelevant, and watchlists are used to parsemessages for target strings including user names, IP addresses, and suspecteddomain names.

Alert events are stored in the IPDB through the NIC logger (not shown at this highlevel). The alerter polls the NIC database every 30 seconds for any configurationchanges and factors these changes into its behavior. Similarly, the alerter checksfor vulnerability and asset data updates every 5 minutes (default), factoring anychanges 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 Explorermodule is a software application that runs on a user PC or laptop. Analysts canrespond to alerts by entering queries to retrieve and examine related events,escalate incidents, refer events to an external ticketing application, and closeevents. All actions are logged as NIC events.

Alerts may be passed to configured output actions to notify analysts that anincident may need handling.

Analysts use the administration GUI for task triage purposes as well as to definethe events, correlation rules, watchlists, and filters used for alerting.


22/67



7. The Vulnerability and Asset Import function provides confidence level filtering tothe alerting function by applying knowledge of specific asset importance andapplication and asset vulnerabilities to IDS alerts before those alerts are triggered.

Vulnerability information is gathered from vulnerability scanners, the NationalVulnerability Database (NVD), and vendor-supplied vulnerability data. RSAenVision Event Source Updates map known vulnerabilities to event sourcessupported by the enVision platform. This information is maintained in theenVision Vulnerability Knowledgebase.

Asset scans contain device, software (operating system), and application versioninformation, IP addresses, and known vulnerabilities. The enVision systemnormalizes this raw information and uses mappings from the VulnerabilityKnowledgebase to create asset signatures (bitmasks) defining the applicability ofvulnerabilities. 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 toconfigure reports and queries and to set filters to tailor the amount of data returnedin a report. All actions are logged as NIC events.

a. All query requests are handled by the NIC Server Service. If IPDB filterinformation is available on the data being requested, that information is usedto find the target target data more efficiently. For more information, seeIPDB Filter Index Calculation and Use.If IPDB filtering is not used,requests are handled by the NIC Server Service which parses each one-minutefile in the IPDB for the target data.

Further filtering may be performed before results are pushed to temporaryreport tables.

b. Report results are collected in a temporary report table where additionalfiltering is done if specified in the query, before passing the results to users forviewing.

Reports can trigger output actions such as a notification that a report hascompleted or failed. A completed report can also be emailed to a list ofrecipients. Reports may also be viewed using the Administration GUI.

9. Event Source Update (ESU) procedures let customers import device definitionfiles for newly supported event sources as well as updating existing devicedefinitions. The ESU also provides new and updated reports and correlation rulesand new and updated vulnerability data that is added to the VulnerabilityKnowledgebase.

Event Source Integrator available on the enVision 4.1 platform and UniversalDevice Support (UDS) let customers write their own device definition files fordevices not supported by the regular ESU program. See Custom Event SourceSupportfor more information.


23/67



10. The Administration GUI provides an administrator and user interface using theunderlying 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 ismanaged 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 andcorrelation rules (Analysts respond to alerts using Event Explorer).

11. The NIC Database Server manages the NIC database, writing and readingenVision configuration information in the database as needed. The NIC DatabaseServer also manages the Vulnerability Knowledgebase and asset database.

In a site with multiple database servers (for enVision 4.1 deployments) or in amultiple site configuration, the NIC Database Server tracks the locations of alldistributed enVision components for managing replication and retrieval of eventmessages from other nodes. Replication client and server components on eachnode 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 theNIC database must be synchronized across all sites in a timely manner. This ensuresthat users and the enVision system function consistently throughout the domain andthat users can access event data whenever needed. Examples of data to be replicatedincludes view configuration information, user accounts, access permissions, assetfingerprint 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 inthe 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 globaldevice location information synchronized with the other sites in the network.

The following diagram shows how all site data uploads to site 10 (the primary mastersite) and how the complete set eventually downloads to all slave sites.


24/67



Site 1 uploads its site directory to Site 7. Site 1 gets all the known site directories fromSite 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, andSite 3 to Site 10. This same process occurs for Sites 8 and 9. After a few iterations ofthe different locator processes, all the sites have data about all the other storagehierarchies in the system.

Data Access

Users may authenticate to and access RSA enVision content and functions in twoways:

The enVision Administration GUI supports browsers connecting over HTTP andHTTPS if SSL is configured on the enVision system. The GUI provides access tothe dashboard and to the major enVision functions of configuring the system, useradministration, configuring alerts, correlation rules, and watchlists, handling alertconditions, configuring alert views, configuring, running, and viewing reports andqueries, and viewing and managing vulnerabilities and assets.

The RSA enVision Event Explorer module is a desktop application designedspecifically for incident management. Security analysts interact directly withenVision alert conditions, responding to them by running queries to confirm orview events about related network or system activities. The Event Explorermodule tracks the status of incidents from the initial occurrance to the eventualclosed state.

Site 7

Site 10

Master Site 10Master Site 10

Site 1 Site 2 Site 3 Site 4 Site 5 Site 6

Locator

Locator Locator Locator Site 8 Site 9

Upload

Site Info

Master Site 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

Master Site 7 Master Site 7 Master Site 7

UploadSite Info

Mast er Sit e 9 Mast er Sit e 9

UploadSite Info

Master Site 9


25/67



RSA enVision Content Extensibil ity

The RSA enVision system may be more closely adapted to customer environmentsand tailored to meet specific customer needs by extending or modifying enVision data

and monitoring tools and by providing customized data to tailor enVision functionalitymore closely to your needs.

Custom Event Source Support

Users can extend the RSA enVision system to handle messages from new or customevent sources.

Event Source Integrator (ESI) available on enVision 4.1 platforms is a menu-basedsystem that customers use to specify device parameters and log parsing informationfor new or custom devices. Customers can also generate device.xml files and add thecompleted files to the enVision system so that your device appears in the GUI alongwith 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 sentusing FTP.

Universal Device Support (UDS), available on enVision 4.0 platforms, is a commandline alternative to the ESI procedures.

Custom Reports

Users can extend the standard reports provided with the RSA enVision system bycreating customized reports to meet specific reporting needs. Users can copy andmodify standard reports, or create custom reports from scratch.

Custom Correlation Rules

The RSA enVision system provides a variety of correlation rules that monitor eventsfor indications of well-known attacks and other alert conditions. These rules aresomewhat generic, as the low-level details of a customer network are not known.Users can customize correlation rules to monitor specific systems for very specificmessages that could indicate an attack or other suspicious activity.

Customers can copy and modify existing correlation rules or they can write rules fromscratch using the Administration GUI.

Correlation rules are grouped into correlation classes defining related families ofcorrelation rules. The Administration GUI provides screens for entering correlationrules 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.


26/67



Bulk data export is provided by a CLI with interactive and scriptable modes. In asingle site deployment, a single bulk data export instance exports CSV data to anexported file share using the Common Internet File System (CIFS) protocol. Thisinstance 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 parsingload incurred by event extraction, particularly if large volumes of data must beexported (for example, at a rate equivalent to the rate at which events are coming intothe site).

Event data export capitalizes on the strength of enVision data collection, making theevent data available for use by external applications. The external data is a copy of thedata 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 acustomer 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 attributeswithin those categories. Asset categories are collections of related attributes. Forexample, the Category named Organization contains the attributes Company,Division, BusinessUnit, Department, Group, and Contact, which define actualparameters.

Some organizations may need to track more attribute categories and attributes than areprovided by default. For example, organizations may want to track a category ofhardware attributes including CPU type, motherboard, RAM, storage type andcapacity, 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 enVisionsystem, users can use a compatible scanner XML file to define and load the attributevalues. As an example, a user could export assets and their properties from the RSAenVision system in an XML file. The user can then modify the XML file to include thenew attributes and their values.

The Administration GUI is used to import completed XML files to your scanner. Thenthe 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 inthe list of supported scanners. Users must configure the enVision system to handle theasset categories and attributes provided by the scanner. Users must also configureSFTP to poll the scanner for asset (XML) files and define the enVision folder for

storing the XML files.


27/67

2: RSA enVision Metadata 27


2RSA enVision MetadataThe RSA enVision alerting and reporting functions rely on event and event sourceidentifiers and other data to carry out their operations. These functions examinevariables and other content within event messages from specific event sources totrigger effective alerts and construct meaningful reports.

Dealing with hundreds of event sources and many thousands of possible eventmessages to find specific variables or other data would pose a daunting task foranalysts. The RSA enVision system provides several kinds of metadata to helporganize event sources and event messages into more manageable groups orcategories and to facilitate examining messages for specific variables or strings. Mostof 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 forefficient 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 groupsthese event sources into device classes and subclasses that you can use to quicklyfocus alert monitoring onto specific kinds of event sources in your network. Deviceclasses can also be included in device groups (see Device Groups) that can be usedto 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 ConfigurationManagement

Application Servers Storage

Analysis Router Mail Servers Database

Anti Virus Switch Mainframe


28/67

28 2: RSA enVision Metadata


The enVision format for showing the device classes and subclasses in the GUI isdeviceclass.subclass. An example is Security.Firewall. You can view the assignmentfor each supported event source in the enVision GUI by clicking Overview > SystemConfiguration > Devices > Manage Device Types.

Users can include the device class and subclass in alerts and correlation rules to focusthe operation on specific parts of the infrastructure. The device class also appears onthe Enterprise Dashboard indicating which part of the infrastructure is most affected.

Event Message Categor ies

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. Eachevent message is assigned to a message category. A message category indicates thetype of message, offering a way to alert and report on similar messages - even whenthose messages are from different event sources. The top level is called the NICcategory. 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


29/67



Each of these categories is divided into alert categories and further divided into eventcategories. The format for displaying message categories in the GUI is a dot-separatedname:NICCategory.alertCategory.eventCategoryand a corresponding ten-digitcategory 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 theenVision GUI by clicking Overview > System Configuration > Messages > ManageCategories.

The following figure shows a five-level message classification, as well as the syntaxfor specifying categories when configuring alerts or conducting an analysis.

Use the message category to monitor for alerts based on event messages withinspecific event categories. Use the category ID to identify the category type in whereclauses when creating reports that use the Global table (the Global table definesgeneric parameters for event messages). Users can add their own message categories(and then subsequently modify or delete them) but they cannot modify or deletecategories provided with the RSA enVision system.

Message Severity Levels

Level categories are single-digit IDs from 1 to 7 that group various alert conditionsbased on their severity. Each event message maps to an alert level. Use the alert levelto monitor the importance of the different alerts occurring at a specific level. The alertlevels 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 requirespecial handling.

6:Informational messages.

7:Debugging messages.

Note: Message categories are referred to as event categories in some places in theRSA enVision GUI.

Attacks.Access.Informational .Network Based .TELNET

NIC Category

Alert Category

Event Categories


30/67



Watchlists

Watchlists are user-defined named collections of strings that represent lists oflike-values such as user names or IP addresses. Watchlists provide a dynamicapproach to processing views and reports. That is, as watchlists are modified, reportdefinitions and alert views relying on them automatically pick up these new values.

Watchlists contain strings of special interest. For example, a single failed logonattempt 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 allevent 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 > SystemConfiguration> Watchlists>Manage Watchlists.

Device Attributes

The RSA enVision system supports hundreds of different event sources that may beused for alerting and reporting purposes. Event source criteria provided with theenVision system consists of the device type which uniquely identifies an event sourcesuch as a Check Point Firewall-1 or a Cisco-PIX firewall. Users can also define devicegroups. Device groups are named collections of event sources based on IP address,device type, or other user-defined device attributes.

Device TypeThe RSA enVision system uses the device type parameter (abbreviated dType) toidentify 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 PointFireWall-1dTypeis checkpointfw1, 3. The name (checkpointfw1) is for humanconsumption in the GUI, reports, and queries. The numeric value (3) is used internallyby the enVision system to find the correct parsing data in the device.xml file to parseagainst.

The device type value may be used in report SQL where clauses to limit reports andqueries to specific event sources.

For example, a report requesting firewall data causes the NIC Server Service to pulldata from several firewall event sources including Check Point FireWall-1, CiscoPixFirewall, CyberGuard Firewall, Palo Alto Networks Firewall, and SonicWALLFirewall. 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 singlefirewall event source type.

You can see the device name and dType parameter for each supported device in theRSA enVision latest update package Help.


31/67



Device Groups

A device group is a named collection of event sources that can be included in a reportor 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 allowedto see along with being a convenient method to filter data. For instance, data beingviewed 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, devicename, device type, device class, and device attributes.

A device group dynamic filter is resolved to the IP addresses each time the filter isapplied so that event sources may change.

A device group static filter is resolved to the IP addresses when it is created so thatevent sources, once defined, do not change.

Other Device Attributes

In the context of a network, event sources have additional device attributes such asdepartment or organization, system administrator, and importance within theorganization.

Users assign these attributes to event sources. This information can be viewed andmanaged using the enVision GUI by clicking Overview > System Configuration>Devices > Manage Monitored Devices. The information may also be imported inbulk. 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 ofattributes such as the device type, collection state, and device class. Users can specifyadditional attributes using either the Manage Monitored Device or Import/ExportDevice user interfaces. These attributes can then be used in alerting and reporting invarious forms of filtering to limit events being considered.


32/67



Summary

The following table summarizes the metadata types.

Metadata Example Usage

device classgroups similartypes of event sourcestogether using a stringformatted asdeviceClass.subclass.

All firewall devices are in thefireweall.securitydeviceclass

Used to filter alerts andcorrelation rules. Can beincluded in a device groupto be used in a report orcorrelation rule.

message categoriesgroupsimilar types of eventmessages together

Messages in the messagecategory Attacks.Accessrepresent a general threat to

the network and should bemonitored closely.

Used to filter alerts andcorrelation rules. Also usedin where clauses for reports

using the Global table.

message severity levelsprioritize event messages byseverity (debugging andinformational to emergencymessages)

Messages of level 0 and 1represent emergencies andalerts where the system isunuseable and needsimmediate action.

Used to filter alerts andcorrelation rules. Also usedin where clauses for reportsusing the Global table.

watchlists can containstrings of special interest tosecurity analysts.

Watchlists can contain stringssuch as source or destinationIP addresses, user names,event IDs, and so on.

Used in Alerting to look forspecific strings in incomingevent messages.

device attributesdefineimplementation-specific,user-defined, andRSA-defined attributes forevent sources

Users must input theseattributes such as Location,Owner, or Importance.

Can be included in a devicegroupto be used in a reportor correlation rule.

device type (dType) is adevice attribute that identifiesindividual event sources

The device type identifiersfor Enterasys Dragon IDS isdragonids, 51.

Used in Report whereclauses

device groupsdefine acollection of event sources

having same deviceattributes.

Create a static device groupto specify one or more deviceattributes.

Used to filter results returnedfrom the IPDB or to filter in

an alert or correlation rule.


33/67

3: Event Collection 33


3Event CollectionThis chapter describes the components involved in event collection and describes theflow of event data through these components. The chapter also describes factorsaffecting 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 serviceseach support a specific collection protocol, such as Check Point (LEA), Windows, or

SNMP. Each of the collection services relays event messages to the NIC CollectorService through a shared memory interface.

The NIC Collector Service collects the event messages received from the collectionservices, as well as messages received through UDP and TCP protocols, and passesthem to the NIC Packager Service as one-minute files. (One-minute files contain allevent messages for a single device received within a sixty second time period.) TheNIC Packager Service unpacks the messages and reorganizes them by device type,event source IP address, and date and time for storage in the Internet ProtocolDatabase (IPDB) along with index and summary files.

The following figure shows the components involved in event collection.

Event Collection ComponentsCollection Services

NICWindowsService

NIC

ODBCService

NIC

TrapdService

NIC File

ReaderService

NIC

WinSSHDService

NIC SDEECollectionService

Index and

Summary Files

To IPDB

Event

Sources

NIC Database Components(supporting all services)

Synchronization with nic.dbdatabases on other nodes in

the domain.

ReplicationServer and Client

Configuration

Database

NIC

DatabaseServerService

nic.db

NICPackager

Service

NIC FW-1LEA Client

Service

One-Minute Files

Event Sources

Logfile Device

SyslogEvent

Sources

InternalenVisionEvents

Logfile Device

SFTP

Plaintext

Logfile Device

NICLoggerService

NICCollectorService

NIC

Win 2008Service

NICVMWare

Collection

Service


34/67

34 3: Event Collection


Collection Services

NIC File Reader Service

The NIC File Reader Service collects events from log files. Event sources generate logfiles that are transferred using FTP or SFTP to RSA enVision appliances containingthe NIC Collector Service and collection services. The NIC File Reader Service usesdifferent modules (DLLs) to parse the various log file formats. The NIC File ReaderService sends the parsed log events to the NIC Collector Service through a sharedmemory interface.

NIC FW-1 LEA Client Service

The NIC FW-1 LEA Client Service is the collection interface to Check Point Firewalllogs. The service leverages OPSEC LEA, a Log Extraction Agent to pull logs fromCheck Point event sources.

Two RSA enVision processes, the Check Point Service (pi_checkpoint) and the CheckPoint Collection Process (cpprocess), handle the collection of log records from CheckPoint servers. The Check Point Service runs as a NIC service under the control of theWindows 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 youconfigure

Monitoring the status of each Check Point Collection Process and restarting theprocesses 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 CheckPoint server

Monitoring the status of the Check Point Service and shutting down if the serviceshuts down

Creating and maintaining the position file associated with the server from whichthe process is configured to collect

For loading purposes, the enVision platform uses permanent or temporaryconnections. A temporary connection is used with a Check Point server that does notgenerate many events. A permanent connection is used with a Check Point server thatgenerates a large number of events.

NIC ODBC ServiceThe NIC ODBC Service collects events from database systems using the OpenDatabase Connectivity software interface.

NIC SDEE Collection Service

The NIC SDEE Collection Service collects events from Cisco Intrusion PreventionSystems. This service is an HTTPS client process that connects to IPS event sources topoll for log files.


35/67



NIC Windows Service

The NIC Windows Service collects events from Windows PCs and servers. This clientprocess 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, Server2008, and Windows 7, using WS-Management services. Administrators mustconfigure connection parameters, time interval, event queries, and device typemappings.

For connecting to systems that use Windows Remote Management authentication andmessage encryption, administrators must take additional configuration steps. Thecollector 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 VMwaremanagement servers. The service implements a VMware infrastructure (VI) SOAPClient that retrieves aggregated events for VMware ESX, ESXi, and VC from aVMware Virtual Center Server through the VI API. The VI Client sends requests to aVI 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 enVisionsystem and does not transmit multiple messages that correspond to the same VMwareevent.

The service implements a data converter that transforms VI-formatted events into anormalized enVision format. After retrieving events from a VI API resident on aVirtual Center Server, the converter parses each event, transforming events into aformat 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 VMwareCollection Service is configured for HTTPS.

parameters to throttle the rate at which events are pushed to the enVision syslogparameters.


36/67



NIC Trapd Service

The NIC Trapd Service is a daemon process on UDP port 162 that listens for SNMPv1or SNMPv2 events and traps.

The NIC Trapd Service uses three methods to collect traps. Each method uses specificDLLs that are explicitly loaded by the main SNMP process based on the event sourcesthat are configured:

The preferred method uses the Parser Trap Handler DLL, which interacts withspecification files to translate traps to syslog messages. A specification file existsfor each device type.

For some event sources, a DLL that is specific to the event source translates trapsto the syslog format. If you configure the RSA enVision system to receive trapsfrom 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 NICdatabase to determine how to translate traps from those event sources to syslogmessages.

NIC WinSSHD Service

The NIC WinSSHD Service listens for SSH connections from event sources sendinglog files to the RSA enVision system. The NIC WinSSHD Service also acceptsconnections from NIC SFTP Agents on Windows systems that do not have their ownFTP 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 internalFTP or SFTP agents. Systems requiring the NIC SFTP Agent include CiscoCiscoWorks, Microsoft Exchange Server, Microsoft IIS, and Oracle runningWindows. For a complete list of these systems, see the RSA enVision Help topicRSA enVision NIC SFTP Agent Configuration.

The NIC SFTP Agent pushes data to the NIC Collector Service through either theMicrosoft FTP Server (only for IBM iSeries) or WinSSHD. The files are processedthrough 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 theCollector 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 LocalCollector (LC) and Remote Collector (RC) nodes. The NIC Collector Service interactswith a set of protocol-specific collection services and aggregates all events comingfrom the event sources.


37/67



In addition, this service supports two built-in protocols: UDP and TCP. The UDPcollection thread can collect between one and four UDP ports depending on specificevent source configurations. Usually, only port 514 is used. The TCP collection threadcan 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 systemcomponents. 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, butit is specifically dedicated to collecting NIC system events for a single or multipleappliance site.

NIC Packager Service

The NIC Packager Service processes the one-minute files. The processing includesreading the files and creating an index file that optimizes and facilitates access to themessages in the one-minute file by event ID. Additionally, the service createssummary files that contain counts and accumulated data from the messages. Finally,the service compresses the three types of files (one-minute files, index files, andsummary 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 eventsoccurring 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 eventsfrom the RSA enVision system.

Device.xml Files

Device.xml is a collection of xml-formatted definition files that map event sourcemessages to message metadata defining aspects of each message for each supportedevent source. The RSA enVision system prepends some mapped metadata to eventmessages when storing the messages in the IPDB.

Reporting, alerting, and query operations rely on the prepended metadata and othermappings provided by device.xml files.

Event Collection Flow

The NIC Collector Service aggregates the messages collected by the collectionservices, and then segregates the messages into one-minute files based on the devicetype and event source IP address.

For each one-minute file created by the NIC Collector Service, the NIC PackagerService 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 messagein the one-minute .dat event files. The metadata ensures that the RSA enVision systemcan find and interpret the messages during lookups for reporting, alerting, and queryoperations.


38/67



The packager creates index files and summary files to speed up queries and reportsand to support summary report generation. For each one-minute file, the packagercalculates an IPDB filter index to indicate the presence of specific variable values inmessages contained in the file, storing each index in the index files. For more

information, see IPDB Filter Index Calculation and Use.All files are compressedand stored incrementally, in the chronological order in which they are received, intothe daily archives.

The NIC Logger Service produces one-minute files containing internal enVision eventmessages, 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,440event files in the .dat archive (60 each hour for 24 hours), 1,440 index files in the .idwarchive, and 1,440 summary files in the .sdw archive. Every hour, a summary fileaggregating the 60 index files and a summary file aggregating the 60 summary filesare created. These two files are compressed and stored in the .isw and .ssw archivesrespectively. Both of these archives contain 24 files at the end of the day. Each eventsource 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 processedevent messages, summary data, and index data in the IPDB file system. The IPDB is apurpose-built file system with a hierarchy of directories facilitating quick lookup. Theservice organizes the data from each Local Collector by IP address, time, and eventcategory for fast lookup by alerting and reporting operations.

CollectionServices1

Event Files

*.dat

Index Files

*.idw

Summary Files

*.sdw

Index Summary

*.isw

Summary Summary

*.ssw

IPDB File System

NICServer

Service

NICTrapd

Service

NIC

Packager

Service

1Partial list of collection services

NIC FW-1

LEA Client

Service

NIC

Windows

Service NIC

Collector

Service

NIC Logger

Service

InternalenVision

Events

Device

XML

SyslogEvent

Sources

One-Minute Files

One-Minute Files


39/67



Log/event data (one-minute files) that are stored in the IPDB include an integrityverification code that can be checked using an RSA enVision utility calledlsmaint.exe. The enVision 4.0 platform uses a CRC-32 error detection code. TheenVision 4.1 platform uses a SHA-256 hash.

The following diagram shows the structure of the IPDB file system and explains thecontent of one-minute files.

Index and summary files contain information about the message types contained in theevent data objects to allow for quicker access to data that is requested during IPDBqueries. 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 filesand statistical information about the number of events of each type and theassociated size in bytes. These files help queries and reports to generate resultsmore 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 indexhelps queries and reports to generate results more quickly.

Summary summary files (.ssw) contain one-day summary roll-up information thatis used for summary reports.

The RSA enVision system provides tamper-evident protection of the data using theintegrity values in the one-minute files. The system also protects the data with accessauthentication.

IPDB Filter Index Calculation and Use

The RSA enVision 4.1 system includes IPDB filter indexing to speed up reports andqueries. An IPDB filter is a space-efficient probabilistic data structure that is used totest whether an element is a member of a set. False positives are possible, but falsenegatives are not.

Event Files

*.dat

One-Minute File (Event Fil e)

IPDB

\envision

\lsnode

\data \col lector name

\device 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 wasprocessed, the normalized event ID, and the offset

into the file where the event is located.


40/67



The NIC Packager service reads the raw one-minute file passed from the NICCollector Service and parses the event messages for specific variable values. Afterparsing, the Packager calculates IPDB filter indices for each variable. On a match, theparser 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 collisionfree. Consequently, some indices may belong to more than one variable value, acondition that can lead to a false positive.

On reading data from the IPDB, the NIC Server Service recalculates the IPDB filtervalue and checks whether the indices are all '1'. If so, the NIC Server Service reads theevents from the corresponding one-minute .dat file.

The following figure shows the Packager storing the IPDB filter index in the header ofthe 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 relevantone-minute file in the IPDB, parsing all contained messages to look for the targetparameter values. Using IPDB filters, the NIC Server Service can just check the IPDBfilter index to determine whether the target parameter value is contained in theone-minute file. This optio

Documents

Envision Architecture