Security Manager to Sentinel Upgrade

The purpose of this document is to guide customers and partners in the planning and execution of upgrading from Security Manager™ (SM) to Sentinel™ 7.3. Sentinel represents the future evolution and merger of both the legacy NetIQ Security Manager and legacy Novell Sentinel product lines. Since upgrading from Security Manager to Sentinel involves some important architectural changes and some component replacements, more consideration than usual must be brought to the upgrade process. This document will help with that process, answer key questions, and provide guidance for the upgrade.

NOTE: The content in this document is up to date as of March 2, 2015. If using a static copy, please check for more recent versions online in the FAQ: https://www.netiq.com/products/sentinel/frequently-asked-questions/security-manager-to-sentinel-migration-faqs.html


Overview

Why should I upgrade? 

Sentinel 7.3 represents the future evolution of both the legacy Novell Sentinel and legacy NetIQ Security Manager product lines. The new product merges the best of both original products to provide powerful and high-performance SIEM features while preserving your investment in an existing data collection infrastructure. The new architecture supports both agentless data collection from many systems and also familiar agent-based Windows, UNIX, and iSeries data collection which can leverage existing NetIQ agent deployments and infrastructure.

What will happen if I do not upgrade?

  • Content currency: The Sentinel product line will ensure that you have the most up to date releases of NetIQ content and solution packs to support security and compliance objectives. Over time, the legacy Security Manager content will no longer be updated.
  • New features and enhancements: The Sentinel development team is very actively developing major new solutions and features including NetFlow support and threat intelligence, among many others. Future Security Manager updates will be limited to fixes and patches only.
  • End of support: As with all products, eventually Security Manager 6.5.4 will reach end-of-life and will need to be replaced with the designated upgrade, namely Sentinel 7.x. NetIQ has a uniform product support lifecycle policy that applies to all products; you can see the target end dates for support for any version of Security Manager or Sentinel here: http://support.novell.com/lifecycle/. We are extending the normal end-of-life dates for Security Manager specifically because of the significant architectural changes required to upgrade to Sentinel 7, and to give you plenty of time to plan the upgrade.

What key benefits will I receive by upgrading?

Sentinel is a full-featured SIEM that provides solutions to a wide variety of security, compliance, and operational use cases. For legacy Security Manager customers, however, the key benefits you will see include:

  • Sentinel's data collection and log management capabilities now include support for existing Security Manager agents as well as lightweight agentless solutions. The entire system is designed to be modular and customizable to support virtually any event source—anything from very popular products to in-house custom applications.
  • Backend storage is fast, embedded (no need for a separate database license), and easy to manage and maintain. Search performance is greatly enhanced and advanced non-repudiation features are supported.
  • Multiple Sentinel instances can be combined using Distributed Search to provide a seamless infrastructure.
  • Sentinel is provided as a traditional software installation or a software appliance. The entire system can be up and running in minutes.
  • Advanced real-time analytics include powerful correlation and statistical anomaly detection.
  • Open architecture provides real-time data sync export and flexible REST APIs.

What functionality will no longer be available?

Generally speaking features and functions available in Security Manager will have equivalent solutions in the Sentinel feature set. In some cases this shift will require you to think a little bit differently about how to solve a given problem; this document provides guidance and step-by-step instructions on how to work within the new architecture and to convert any custom-developed work over to the new platform. Here is a brief list of the major Security Manager components and features that are now deprecated, with their rough Sentinel equivalents.

Security Manager Component(s)/Feature(s)Sentinel Equivalent Component(s)
Log Archive Server

Sentinel event storage (files indexed by Lucene)

[Refer to the 'Configuring Data Storage' section of the Administration Guide on the Sentinel 7.3 Documentation Website]

Forensic Queries

Event Search in the Sentinel Web Interface

[Refer to the 'Searching Events' section of the User Guide on the Sentinel 7.3 Documentation Website]

Reporting Server and Trend Analysis

Sentinel Reports and Analytics (based on Jasper)

[Refer to the 'Reporting' section of the User Guide on the Sentinel 7.3 Documentation Website]

Correlation Server

Correlation Engine (pattern detection)

[Refer to the 'Correlating Event Data' section of the User Guide on theSentinel 7.3 Documentation Website]

and

Security Intelligence (anomaly detection)

[Refer to the 'Analyzing Trends in Data' section of the User Guide on the Sentinel 7.3 Documentation Website]

Web Console

Sentinel Web Interface hosted on the Sentinel server

[Refer to the 'Sentinel Web Interface' section of the Administration Guide on the Sentinel 7.3 Documentation Website]

Control Center

Functionality of the SM Control Center is distributed across the following Sentinel components:

Sentinel Web Interface on the Sentinel server

[Refer to the 'Sentinel Web Interface' section of the Administration Guide on the Sentinel 7.3 Documentation Website]

and

Sentinel Control Center

[Refer to the 'Sentinel Control Center' section of the Administration Guide on the Sentinel 7.3 Documentation Website]

and

Agent Manager Console

[Refer to the 'Understanding the Agent Manager Console' section of the Sentinel Agent Manager User Guide on the Sentinel 7.3 Documentation Website]

Central ComputerSentinel Agent Manager (SAM) service (Central Computer)
Development Console

Agent Manager Console

[Refer to the 'Understanding the Agent Manager Console' section of the Sentinel Agent Manager User Guide on the Sentinel 7.3 Documentation Website]


Planning for Your Upgrade

Who will need to be involved in the upgrade?

  • System Administrators: Upgrading to Sentinel typically involves rolling out at least one new server to host the core Sentinel components, plus the Sentinel Agent Manager (SAM) setup process will require the user to be a system administrator on the (Microsoft Windows) computer system that hosts the Sentinel Agent Manager Server. System administrators may also be involved in decommissioning one or more legacy Security Manager components once they are no longer needed.
  • Database System Administrator: The user who is installing the product will require database system administrator access to the SQL Server instance hosting the Sentinel Agent Manager databases. Note that Sentinel Agent Manager (SAM) now supports SQL 2012 Express Edition. 
  • Security Manager Administrator: The Sentinel Agent Manager installation provides an option to migrate agents from an existing Security Manager (SM) installation. The process will create a second database to hold the agent information within the same SQL Server instance, and then migrate the SM agents from the old database to this new database. The Security Manager Administrator should help guide which agents should be brought over when and how they should be configured.
  • UNIX Agent Administrator: If you are using the Security Manager UNIX Agents, the UNIX Agent Administrator will need to push out a new configuration to the UNIX Agent to send event data to Sentinel Agent Manager (prior to UNIX Agent 7.4) or a Sentinel Collector Manager (UNIX Agent 7.4).
  • Security Analyst: The new Sentinel system includes a variety of out of the box rules and reports, including content previously contained within Security Manager (although this content has been transformed and updated significantly). A Security Analyst should be engaged to review the provided content and deploy the rules/reports of interest to support the environment.

What new architectural components will I need?

The general upgrade process involves installing a new Sentinel instance in the environment, installing a new Sentinel Agent Manager, and then migrating existing legacy Security Manager (SM) agents over to the new platform. The agents can be migrated in bulk or incrementally per your preference, and events collected by SM in the interim can be forwarded to the new Sentinel instance to ensure comprehensive coverage even during a staged upgrade process.

You will need to install at least one new core Sentinel Server, which can be either a traditional software installation (on SUSE Linux or RedHat) or a soft appliance (a virtual machine (VM), or a fully-managed bare-metal image). The hardware required to support this new server depends on several factors, the most important of which is the rate at which event data is collected. Details are available in the 'Meeting System Requirements' section of the Installation and Configuration Guide on the Sentinel 7.3 Documentation Website.

Sentinel uses a separate service to handle event data collection called a Collector Manager; this can run either on the core server or be offloaded to one or more remote servers (depending on how much load must be handled). Sentinel Agent Manager (SAM) is an additional Windows-based component that runs separately to manage Windows agents, collect events from them, and then forward that event data to a Collector Manager. The Sentinel Agent Manager server and database can typically be installed on a single system; 4 CPU cores with 4GB of memory is typically sufficient to manage several thousand agents at several thousand events per second in the aggregate. For large environments, multiple Sentinel Agent Manager servers can be deployed. See the 'Planning to Install Sentinel Agent Manager' section of the Sentinel Agent Manager Installation Guide and the 'Meeting System Requirements' section of the Installation and Configuration Guide on the Sentinel 7.3 Documentation Website for more detailed sizing requirements for Sentinel Agent Manager and for Collector Managers respectively.

Existing UNIX Agent Managers continue to be used to manage UNIX Agents that were deployed with SM. The Agents will need to be re-configured to send event data to Sentinel instead of SM.

Sentinel also includes a Correlation Engine component which often runs on the core server, but can be offloaded to a separate system if there are many or very complex rules.

How long should I expect the upgrade and agent migration to take?

The answer to this depends a lot on your existing environment and how many customizations you have made, plus your own decisions on how aggressively to migrate your customizations into the Sentinel environment. The good news is that we've left this very flexible—you can move over all the SM agents at once, or stage them in batches. Furthermore, data that is still being collected via the SM agents that have not yet been migrated can be forwarded to Sentinel, ensuring comprehensive coverage even in the middle of this process.

The Sentinel installation process itself (core server, Collector Manager(s), and Sentinel Agent Manager) is fairly easy and quick. For a full installation, it should not take more than an hour to complete the installation. If you plan to use the soft appliance version of Sentinel, this could be even faster.

During the Sentinel Agent Manager installation process, you will be prompted to identify any existing SM environments to connect to for migration. The Agent Migration Utility allows you to select one or more SM agents to migrate as part of this process; migration itself is fairly quick but note that during the migration any customized agent policies are replaced by default Sentinel policies.

Infrastructure Planning

What sort of hardware will I need to support the new Sentinel services?

The capacity of new systems to support your new Sentinel services will depend primarily on how busy your current environment is, with some other minor factors such as the extent to which data will be analyzed in real-time. The general hardware and other requirements for new Sentinel installation can be found in the 'Meeting System Requirements' section of the Installation and Configuration Guide on the Sentinel 7.3 Documentation Website, but note that these are general guidelines that might not be appropriate for all environments. If in doubt, reach out to your NetIQ sales team or work with one of our qualified services partners to create a more refined environment analysis.

If I need to figure out existing load levels of SM components, how do I do so?

Since the primary factor that determines the required size of Sentinel components relates to the amount of event data collected, the equivalent statistics in the SM environment should be useful to help you plan the new environment.

There are two ways to get this information:

  • The Log Archive Configuration Utility statistics page shows the number of events collected per day in the log archive. Divide this by 86400 (the number of seconds in a day) to get the average events-per-second (EPS) rate.
  • The NetIQ Security Manager - Log Handler performance counters on the Central Computer measure the EPS forwarded to the Log Archive.

What (specific) SM resources will I be able to decommission/downgrade?

After the upgrade is fully complete, certain legacy SM components will no longer be necessary and can be retired from the environment. Each customer should reevaluate the sizing needed for Sentinel as opposed to SM since the customer may be able to retire some Central Computers.

The components that can be retired include:

  • SM Log Archive Server
  • SM Reporting Server
  • SM Correlation Server
  • SM Web Console Server
  • SM Control Center, Development Console and Web Console
  • SM Central Computer (once it no longer monitors agents, it can be uninstalled and retired or repurposed for use as a Sentinel Agent Manager central computer)
  • The legacy SM database server (can be decommissioned only after the SM database has been migrated to the Sentinel Agent Manager database server and separate servers are used for both the SM and Sentinel Agent Manager databases)

Integration Planning and Preparation

At a high level, how will data collection change after the upgrade?

In SM, the operating system agents performed a number of functions including event collection, normalization, filtering, correlation, and alerting. Events and other data collected by the agents were sent to the Central Computer, which then routed that data to SM's Log Archive Server and the real-time database on the database server. Network-based sources sent data directly to the SM agents for processing, and database sources were polled directly by the SM agent as well.

In Sentinel, the intelligence on how to interpret data from a given source resides primarily in a plug-in called a Collector, which runs on a service component called a Collector Manager (part of the Sentinel environment). Collectors often support multiple event collection protocols, and for operating systems such as Windows and Linux they support both agent-based and agentless event collection. By centralizing this function, Sentinel provides more flexibility while also offloading resources from the agents; this also implies that common rules can be applied to both agent-collected and remote-collected events or even, due to Sentinel's strong normalization techniques, these rules can be applied across multiple different types of resources. As a simple example, a policy such as "generate an alert if more than six failed logins against a single account are observed" would require separate rules for each different type of source under SM, under Sentinel this is a single rule that applies to all event sources that report logins.

From an architecture perspective, the agent-collected event data flows up to the Sentinel Agent Manager and is then forwarded to the appropriate Collector for processing (with UNIX Agent 7.4 and later, event data for UNIX systems is sent directly to the Collector Manager). Events flowing over network, JDBC, or other protocols not using agents are collected directly by Sentinel plug-ins.

Do I need to collect any information from existing SM components before the upgrade?

Access to the SQL Server instance hosting the existing SM agent databases will be necessary to migrate agents. Also, if you have customized any content (rules) on the agents, you may need to review your changes and re-implement those changes on the Sentinel side (see below).

I have customized some of my SM content, how can I find out what I'll need to convert to the new Sentinel format?

NetIQ has prepared a Sentinel Agent Manager Migration Assessment Tool, which will scan your existing environment and present information about your existing agents and any customized rules that are deployed. You can then use this information to help plan your upgrade and how and when you will migrate the Security Manager customized rules into the Sentinel format (information on how to map Security Manager concepts to Sentinel concepts is included in this FAQ). Download the SAM Migration Assessment Tool from the Sentinel Plug-ins page under the Utilities tab.

Do I need to prepare or change any SM components or configuration before I upgrade?

No, as long as Security Manager and its agents are already updated to at least version 6.5.4. When installing Sentinel Agent Manager with the intention of migrating agents from SM, the Sentinel Agent Manager installation process provides an Agent Migration Utility to make the process easier. No additional configuration is required on the SM environment for this purpose, although cleaning up any orphaned agents or other issues—a general health check—is good practice.

Will any specific SM features stop working after the upgrade?

As described above, Sentinel takes a different architectural approach with respect to event collection, filtering, correlation, and alert generation. As a result, some of the legacy SM concepts you may be familiar with do not translate directly to the Sentinel environment. A short list is presented here, but more information is available below to support your particular use cases.

  • The agents will no longer perform event processing rules in order to raise an alert or execute an action for an alert. Events are processed in Sentinel through correlation rules, which provide very similar pattern-matching operations. The output from correlation rules will typically generate another event called a correlated event, but correlation rules can also be hooked up to a modular Action framework to perform a wide variety of activities.
  • One or more Actions (which are similar in concept to alert responses in SM) can be associated with correlation rules to fire automatically when the rule matches some input. There are a few "built-in" Actions that perform various internal functions, but Sentinel also provides a set of standard JavaScript-based, customizable Actions that can trigger a wide range of external activity such as sending e-mail, forwarding events to remote systems, creating Remedy tickets, etc).
  • Actions can also be executed manually against a selected set of events within Searches, Active Views, or Incidents within Sentinel. Actions can also be used to process streams of data selected by Event Routing rules.

Upgrade Process

Pre-requisites

Before you begin the upgrade process, make sure the following pre-requisites are in place:

  • Security Manager and the SM Windows Agents should all be upgraded to at least version 6.5.4.
  • Sentinel is installed and operational per the Installation and Configuration Guide on the Sentinel 7.3 Documentation WebsiteThe Sentinel environment should sized to handle the anticipated event processing load from the environment.
  • A SQL Server instance is available to host the new SAM database; use one of the SQL Server versions mentioned in the 'Installing Microsoft SQL Server' section of the Sentinel Agent Manager Installation Guide on the Sentinel 7.3 Documentation Website.
  • You have SQL credentials for the existing SM database (the Sentinel Agent Manager installer will use these to pull agent migration information).  
  • Hardware is configured for the new Sentinel Agent Manager service according to the pre-requisites mentioned in the 'Planning to Install Sentinel Agent Manager' section of the Sentinel Agent Manager Installation Guide on the Sentinel 7.3 Documentation Website.

Initial Setup

Once the pre-requisites have been fulfilled, a good starting point is to review the Sentinel Agent Manager Migration Guide on the Sentinel 7.3 Documentation Website. It will go over the process of migrating existing SM agents to SAM. It provides the steps to use the Agent Migration Utility and will provide insights in strategies that can be implemented for the migration. To invoke the Agent Migration Utility, please select 'Yes' when the option to 'Repurpose Security Manager installation for use with this Agent Manager' is presented.

The initial setup will include the installation of the following SAM components:

  • The Sentinel Agent Manager databases on the new SQL Server instance.
  • The Sentinel Agent Manager service (Central Computer) and console.

These components can be installed on a single new SAM server. Additional SAM services can be added later if the number of agents and/or event rates grow very large.

During the initial setup, there are two essential configurations that must be completed:

  • Configuring the Sentinel server name in Sentinel Agent Manager: This is the Sentinel server or Sentinel Collector Manager. SAM will forward the agents' data to this server. You will be prompted for this information during the SAM installation process, or it can be later modified from the SAM Agent Manager Console.
  • Configuring the SAM database server in Sentinel: This is the SQL Server instance containing the SAM database, Sentinel manages the agent policies through the SAM databases. You can configure this information through the Sentinel console.

Taking Over Windows Agents

As the SAM components are installed, the setup program will inquire about the existing SM database and install an Agent Migration Utility. The Agent Migration Utility allows you to re-assign Windows, Unix, and iSeries agents from the SM environment to Sentinel Agent Manager. The migration utility allows you to select a single agent or multiple agents to re-assign.

Required steps prior to migrating agents from SM to SAM:

  • Ensure that the SM Windows agents intended for migration are upgraded to version 6.5.4 or later. You can view the version information attributes for an SM agent in the Infrastructure View in Control Center console of SM.
  • Ensure that the SM Windows agents intended for migration are online and accessible. You can view the online status of an SM agent in the Infrastructure View in Control Center console of SM.

The Agent Migration Utility shows the status for each migrating agent.  The 'Agent Migration Status' section of the Sentinel Agent Manager Migration Guide on the Sentinel 7.3 Documentation Website has details for each possible migration status and troubleshooting steps in case you run into problems.

Taking Over Unix Agents

SM Unix Agents can be reconfigured to send event data to Sentinel by pushing out new configuration information with UNIX Agent Manager.

  • For Unix Agent 7.4 and later, push out a new configuration with the Sentinel Collector Manager IP address and the Sentinel Agent Manager Connector Port (default 1590) to the agents. Event data will be sent directly from the Unix Agent to the Sentinel Collector Manager.
  • For Unix Agents prior to 7.4, push out a new configuration with the Sentinel Agent Manager IP address and the Sentinel Agent Manager Server Port. Event data will be sent from the Unix Agent to Sentinel Agent Manager, and from there to Sentinel.

Fresh installs and deployments from UAM will request the Sentinel configuration automatically.

Taking Over iSeries (IBM i) Agents

At the time this document was released, the completed instructions for migrating iSeries Agents were not yet available. Contact Technical Support for assistance.

Integration and Content Guidance

After you have completed the upgrade process and data is flowing in to Sentinel, you will find a rich variety of out of the box content including filters, rules, reports and other items that will help you achieve your security objectives. Most of the integration components and content from Security Manager has been re-implemented in Sentinel as part of the core product, but there are a few items that were migrated—either because the component seemed to be obsolete, or because we could not identify enough customers that were actually using that component. This section walks through the list of out of the box Security Manager integration and content, and maps it to Sentinel equivalents.

Security Manager Modules (Sentinel Collectors)

One of the primary functions of SIEM and Log Management is to collect, parse, and normalize event data from various third-party products. In SM, this function was performed by a component called a Module; in Sentinel, the equivalent is called a Collector. This section maps Security Manager Modules to equivalent Sentinel Collectors which serve the same function. Note that the event collection method, event source configuration, parsing logic, and other details may not be identical between the listed components. Refer to the individual plug-in documents for more details.

If you have products in this list (or not in this list) that are not currently supported under Sentinel, you have a number of options:

  1. Check the current list of support Sentinel Collector Plug-ins is available on our support website. NetIQ Engineering is constantly working on new Plug-ins, and you may find your product listed there.
    • You may also check our Plug-in preview site, which lists Plug-ins that are in the process of being developed.
  2. Request information about your product from the NetIQ Sales team. The relative priority for building support for a given product is driven by customer demand, so the more customers we have asking about a particular product the more quickly it will be supported. Your sales team can also help you understand where a given product currently is on our priority list.
  3. If support for your product will not be officially available in the timeframe you desire, you can engage NetIQ Consulting or any of our qualified partners to help build the Collector for you. Cost varies depending on how complex and proprietary the event source is, but most standard Collectors are usually delivered with a few days' worth of work.
  4. Alternatively, you can build a new Collector yourself. NetIQ publishes a full Plug-in SDK that you can use to create your own Collectors, with full documentation and even training.
ApplicationSentinel Plug-inDescription
Cisco IP TelephonyNot yet availableTo date, NetIQ has not identified enough customers using this component to justify the costs of developing a replacement. If you require integration with this source, please contact your NetIQ Sales team for further information.
NetIQ Directory and Resource AdministratorNot yet availableSupport for this integration is planned, but not yet available. If you require integration with this source, please contact your NetIQ Sales team for further information.
NetIQ Vulnerability Manager (Secure Configuration Manager)Not yet availableSupport for this integration is planned, but not yet available. If you require integration with this source, please contact your NetIQ Sales team for further information.
Security ManagerNetIQ Agent Manager collector

Security Manager 6.5.4 will continue to be supported via this plugin until End of Life. This collector also supports internal/diagnostic messages raised by Sentinel Agent Manager.

Bit9 ParityNot yet availableTo date, NetIQ has not identified enough customers using this component to justify the costs of developing a replacement. If you require integration with this source, please contact your NetIQ Sales team for further information.
Blue Coat ProxySGBlue Coat ProxySG AppliancesSupported out of the box in Sentinel.
Check PointCheck Point Security GatewaysSupported out of the box in Sentinel.
Cisco FirewallsCisco FirewallSupported out of the box in Sentinel.
Cisco IOSCisco Switch and Router (and others)Support for Cisco IOS is present in the Cisco Switch and Router plug-in but is tuned for those sources; compare the product of interest with the list of supported devices available on the plug-in website for other Cisco IOS sources.
Cisco Secure ACSCisco Secure Access Control ServerSupported out of the box in Sentinel.
Microsoft Internet Information ServerMicrosoft IISSupported out of the box via Sentinel Agent Manager.
Imperva SecureSphereImperva SecureSphereSupport for this component is available now. Refer to Sentinel Plug-ins page.
iSeriesIBM iSeriesSupported out of the box via Sentinel Agent Manager.
ISS SiteProtectorIBM Proventia Network Enterprise ScannerSupported out of the box in Sentinel.
Juniper Networks IDPJuniper IDP SeriesSupported out of the box in Sentinel.
Netezza MantraNot yet availableNetezza Mantra is End of Life and no plans exist to support this product in Sentinel.
McAfee VirusScan EnterpriseMcAfee VirusScan Enterprise/McAfee ePolicy OrchestratorSupported out of the box in Sentinel. Data can be collected direct from the product or via McAfee ePolicy Orchestrator.
Microsoft ExchangeMicrosoft Exchange ServerSupported out of the box via Sentinel Agent Manager.
Microsoft Internet Security and Acceleration ServerMicrosoft ISA ServerSupported out of the box in Sentinel.
NetApp FilerNot yet availableSupport for this component is planned, but not yet available. If you require integration with this source, please contact your NetIQ Sales team for further information.
NetScreen FirewallJuniper Netscreen SeriesSupported out of the box in Sentinel.
Oracle on UnixOracle DatabaseSupported out of the box in Sentinel. More advanced support planned but not yet available.
Secure Computing SidewinderMcAfee Firewall EnterpriseSupported out of the box in Sentinel.
SnortSourcefire SnortSupported out of the box in Sentinel.
Symantec Endpoint ProtectionSymantec Endpoint ProtectionSupported out of the box via Sentinel Agent Manager.
Third Brigade Deep SecurityNot yet availableTo date, NetIQ has not identified enough customers using this component to justify the costs of developing a replacement. If you require integration with this source, please contact your NetIQ Sales team for further information.
TippingPointTippingPoint Security Management SystemSupported out of the box in Sentinel.
Trend Micro OfficeScanTrend Micro OfficeScanSupported out of the box in Sentinel.
Trend Micro ScanMailTrend Micro ScanMailSupported out of the box in Sentinel.
Tripwire EnterpriseNot yet availableTo date, NetIQ has not identified enough customers using this component to justify the costs of developing a replacement. If you require integration with this source, please contact your NetIQ Sales team for further information.
Type80 SyslogNot yet availableTo date, NetIQ has not identified enough customers using this component to justify the costs of developing a replacement. If you require integration with this source, please contact your NetIQ Sales team for further information.
Unix (multiple platforms)

NetIQ UNIX Agent and

Others

Supported out of the box via Sentinel Agent Manager.

Sentinel also supports agentless collection from a variety of UNIX-style platforms, including AIX, Solaris, HP-UX, RedHat Linux, and SUSE Linux.

VMWare ESXiVMWare ESXiSupport for this component is now available. Refer to the Sentinel Plug-ins page.
Microsoft WindowsMicrosoft Active Directory and Windows

Supported out of the box via Sentinel Agent Manager. Use the Agent Migration tool to move agents from Security Manager into Sentinel Agent Manager.

Sentinel also supports agentless collection using a proxy component.


Security Manager Processing Rules (Sentinel Correlation/Anomaly Rules, Actions, etc)

This section describes how common Security Manager Processing Rules are typically implemented within Sentinel, which uses a different paradigm.

Security ManagerSentinel
Alert on or respond to event (Event rule)

Sentinel does not generate an exact equivalent to an alert at this time, although correlated events and/or incidents are similar concepts. In order to alert a user that some specific activity occurred, a correlation rule configured to send an e-mail or notify the security administrator can be created. The notification is achieved using Actions associated with the rule.

To generate a response to specific events, create a correlation rule in the Sentinel Web Interface whose criterion matches that of the events to be detected. Associate an action with this rule, which acts as a response to the generated events.

Refer to the 'Correlating Event Data' section of the User Guide and the 'Configuring Actions' section of the Administration Guide on the Sentinel 7.3 Documentation Website for details on correlation and actions respectively.

Filter Event (Filtering rules)

Sentinel does not implement multiple channels from the agent to the backend—all events pass through a single channel to the Collector and are then routed to real-time analytics and/or storage by the backend.

  • Pre-filter: Refer to the guidance for the SM rule 'Filter Event (Log Filter Rule)'. Since at the agent level Sentinel does not implement separate channels for real-time and log-archive events, the implementation of the Pre-Filter rule is similar to that of the Filter Event rule.
  • Database filter: The database filter in SM allows an event to match one or more data processing rules and respond to the event but prevent the event from being stored in the OnePoint database. In Sentinel, this type of filtering is done by a Routing Rule on the backend, so database filters are not applicable.
  • Conditional filter: The conditional filter in SM specifies that if an event matches one or more data processing rules, the event will be stored in the OnePoint database only if the event matched rules other than the conditional filter. Sentinel would treat this as two separate routing decisions implemented using Routing Rules in the backend. Refer to the 'Configuring Event Routing Rules' section of the Administration Guide on the Sentinel 7.3 Documentation Website for details on Event Routing Rules.
Detect Missing Event (Missing Event Rule)

Sentinel does not support detection of a specific missing event within the agent.

However, for agentless monitoring, an event source can be configured so that Sentinel generates an event called 'NoDataAlert' if that source does not generate any events for the specified time. Refer to the Connector documentation on the Sentinel Plug-ins page for details on how this can be configured. In other scenarios, correlation rules can be constructed to detect missing events in certain types of patterns.

Consolidate Similar Events (Consolidation Rule)

Event consolidation in SM helped to suppress individual responses for multiple events of the same type, and also helped construct a consolidated event with a count of the similar events.

Correlation in Sentinel can be used to detect similar events or repeated patterns, but the response to those rules is treated independently, and can be configured to suppress repeated output and consolidate all related activity into a single response. Hence, Consolidation Rules are no longer needed in Sentinel.

Collect Specific Events (Collection Rule)

SM stored events at two different locations: The Log Archive Server for archival events and the OnePoint database for real-time events. Collection Rules helped with rule diagnostics required because of this separation.
Sentinel eliminates this separation, and all events are stored in the Event Store. Hence this rule type is no longer required.

Correlate Events (Correlation Rule)SM used this rule to detect patterns of events. Create a correlation rule in the Sentinel Web Interface for similar functionality. Unlike Security Manager, Sentinel does not require correlation collection rules. Refer to the 'Correlating Event Data' section of the User Guide on the Sentinel 7.3 Documentation Website for details on correlation.

Collect Logs for Archival (Log Collection Rule)

In Sentinel, use Data Collection Rules in the Agent Manager console to collect relevant events from agents. For corresponding agentless sources, you can use filters on the Event Source Management view or Routing Rules to filter out unwanted events.

Once the appropriate events are collected, you can use Routing Rules to direct the appropriate sets of events to the real-time analytics, storage, or both.

Refer to the 'Configuring Data Collection' section of the Administration Guide on the Sentinel 7.3 Documentation Website for details on data collection and the 'Configuring Event Routing Rules' section of the Administration Guide on the Sentinel 7.3 Documentation Website for details on Event Routing Rules.

Filter Archival Event (Log Filter Rule)

These rules filtered events collected by agents. In Sentinel, events can be filtered by Data Collection Rules in the agents, by filters on Event Source Management data collection nodes, or by Routing Rules. The Routing Rules can also be used to direct the appropriate sets of events to real-time analytics, storage, or both.

Refer to the respective collector and connector documentation at Sentinel Plug-ins, and the 'Configuring Event Routing Rules' section of the Administration Guide on the Sentinel 7.3 Documentation Website for details on Filters and Event Routing Rules respectively.

Sample Performance Data (Measuring Rule)

Sentinel does not collect performance data. Hence, measuring rules are not supported.

Compare Performance Data (Threshold Rule)

Sentinel does not collect performance data. Hence, threshold rules are not supported.

Respond to Alert (Alert Rule)

Sentinel does not generate alerts with exactly the same semantics as SM, hence Alert Rules are not required. To notify users about certain activity, use Actions as mentioned under 'Event Rule'.
Correlation Collection RulesSentinel does not require correlation collection rules for collecting events for correlation.


Security Manager Data Providers

Security ManagerSentinel
Windows NT Event Log

Sentinel supports both agentless and agent-based collection of these logs.

For agentless data collection from Windows Event Logs, use the Windows Event (WMI) Connector. This Connector supports monitoring of any Windows Event Log that exists on the target server using WMI. Refer to the Connector documentation available at the Sentinel Plug-ins site for details on using and configuring this Connector.

Some of the Event Logs collected may require specific Collectors to parse the data fully. Refer to the documentation available at the Sentinel Plug-ins site for details on the available Collectors.

For agent-based monitoring, the Windows Event Log provider is supported in Sentinel Agent Manager for the following log types:

  • Application
  • System
  • Security
  • DNS Server
  • File Replication
  • Directory Service

The provider can be configured in the Agent Manager Console. However the event parsing logic is no longer applied at the agent; you will need to deploy the appropriate Collector to handle the events.

Application Log

Sentinel supports data collection from file-based sources using both agent-based and agentless methods.

The Application Log provider is supported in Sentinel Agent Manager with one type of log file—"Generic Single-line Log File". This can be used for agent-based data collection from single-line log files. The parsing intelligence is no longer applied within the agent, the collected file data is passed to a Collector for parsing. You will need to deploy the appropriate Collector to handle the events.

For other types of application logs as well as agentless data collection, use the File Connector. This Connector provides a wide range of options for specifying the type of file to be monitored. Refer to the documentation available on the Sentinel Plug-ins site for details on using and configuring this Connector.

OPSEC Provider

Sentinel supports agentless data collection from Check Point sources.

Use the Check Point (LEA) Connector to collect data from Check Point sources. Refer to the documentation available at Sentinel Plug-ins for details on using and configuring this Connector.

Timed EventSentinel does not create or collect Timed Events.
WMI Events

There are no separate Connectors for collecting extrinsic and intrinsic WMI events.

To capture SNMP traps, the SNMP Connector can be used.

To collect events on service status, the Windows Event (WMI) Connector can be used to query the Windows System Event Log.

These events can be collected only using agentless monitoring. Refer to the documentation available at Sentinel Plug-ins for details on using and configuring this Connector.

Syslog

Sentinel supports agentless collection of syslog events using the Syslog Connector. Refer to the documentation at Sentinel Plug-ins for details on using and configuring this Connector.

Sentinel will attempt to automatically detect the type of any new source and assign that source to the appropriate Collector (each Collector registers a set of rules used to identify data from sources it understands).

If you have configured syslog sources to send events to your SM environment, you will need to re-point those sources to the new Sentinel Collector Manager or convert the original SM syslog target IP to an IP alias.

Windows Event Proxy Provider

Use the Windows Event (WMI) connector for collecting remote Windows Event Logs. This Connector supports monitoring of any Windows Event Log that exists on the monitored computer using WMI.

Some of the Event Logs collected may need specific Collectors to parse the data fully. Refer to the documentation available at Sentinel Plug-ins for details on available Collectors.

Windows NT Performance CounterWindows performance data is not collected by Sentinel.
WMI Numeric eventsWMI numeric data is not collected by Sentinel.
Generic

The Generic provider was used in SM for the purpose of internal eventing only.

This provider is not applicable in Sentinel.


Scripts

In SM, scripts were used to respond to various events and to collect information that was not collected using processing rules.

In order to respond to events received by Sentinel, a correlation rule which matches that event is created and an Action is associated with that rule to respond to it. Integrators can be used to extend the functionality of Actions and connect to an external system. Both run on the Sentinel server. Note however that Sentinel does not currently have a mechanism to respond to Timed Events, which are not produced or collected by Sentinel.

Several Actions and Integrators are provided with Sentinel. Additional Actions and Integrators can be added from the Sentinel Plug-ins site, and completely custom Actions can be created using the Sentinel Plug-in SDK. For more details on Actions and Integrators, refer to the sections 'Configuring Actions' and 'Configuring Integrators' respectively of the Administration Guide on the Sentinel 7.3 Documentation Website.

Sentinel does not collect data generated by scripts. Connectors are used to collect data in Sentinel. Refer to the documentation of the available Connectors at Sentinel Plug-ins for details on what types of data can be collected and how the collection can be achieved.


Terminology Updates

Security Manager termSentinel Agent Manager termDescription
Development Console[Sentinel] Agent Manager Console

The Agent Manager Console is used to define data collection policies for and management of Windows agents. It also allows you to add, remove, modify, and set connection intervals for Unix and iSeries agents.

You can continue to use Unix Agent Manager for configuring data collection and management of Unix agents.

Use the Security Solutions for iSeries product for management of iSeries agents.

Refer to the 'Understanding the Agent Manager Console' section of the Sentinel Agent Manager User Guide on the Sentinel 7.3 Documentation Website for details on the Agent Manager Console.

Processing Rule GroupData Collection Policy

Data collection policies are containers that let you categorize and organize your data collection rules by application or topic. The supported rule types are: Data Collection Rule and Filter Data.

Data Collection Policies can be nested within one another. They are associated with Device Groups to indicate the data collection policy should be distributed to all agents in the Device Group.

Data Collection Policies are created in the Agent Manager Console. The association between Data Collection Policies and Device Groups is done in the Sentinel Web Interface.

Refer to the 'Understanding Data Collection Policies' section of the Sentinel Agent Manager User Guide on the Sentinel 7.3 Documentation Website for details on Data Collection Policy.

Computer GroupDevice Group

A Device Group is a collection of hosts with something in common, for example a group of all computers with Norton AntiVirus installed. Data Collection Policies assigned to a Device Group are deployed to all agents in the group.

Device Groups are created in the Sentinel Web Interface. Access to this feature will be available only after configuration of the Sentinel Agent Manager database integration on the Sentinel server.

Refer to the 'Understanding Device Groups' section of the Sentinel Agent Manager User Guide on the Sentinel 7.3 Documentation Website for details on Device Groups.

Computer RuleDevice Group Definition

A Device Group Definition is a logical expression built from Device Attribute Definitions used to define a set of computers with similar characteristics or purpose. This is essentially a rule that is used to determine whether a particular host, with particular attributes, is a member of the Device Group or not.

Device Group Definitions are created in the Sentinel Web Interface. Access to this feature will be available only after configuration of the Sentinel Agent Manager database integration on the Sentinel server.

Refer to the 'Understanding Device Groups' section of the Sentinel Agent Manager User Guide on the Sentinel 7.3 Documentation Website for details on Device Group Definition.

Computer AttributeDevice Attribute Definition

A Device Attribute Definition is a collection of values that identify computer attributes, such as the operating system, installed applications, or versions thereof.

Device Attribute Definitions are created in the Sentinel Web Interface. Access to this feature will be available only after configuration of the Sentinel Agent Manager database integration on the Sentinel server.

Refer to the 'Understanding Device Groups' section of the Sentinel Agent Manager User Guide on the Sentinel 7.3 Documentation Website for details on Device Attribute Definition.

 


Let's Talk


Welcome, Want to talk to someone? Call our Sales team or request a call and we'll get right back to you.

  • Sales: (888) 323-6768

For support information, please visit Technical Support.