Overview of the Snare Server and Snare Agents for PCI DSS Compliance

The intent of PCI DSS - Requirement 10 is to ensure that controls are in place to safeguard cardholder information. The Snare Server is used to report on certain events created by the native operating systems, applications or appliances. It is recommended that a risk assessment be conducted when developing an audit and event monitoring strategy. The following ideas are presented as a guide as to how the Snare Server will meet the basic guidelines of Requirement 10.

Note: It is strongly recommended that this collection profile be guided by the outcomes of an agency's risk assessment and security policy.

Network devices:
All management and security events, and failed connections. The management events should include events such as general reconfiguration, reboots and password changes. Usually, events produced by these devices are sent out via SYSLOG, and not controlled by a Snare agent. In which case, the device should be configured to send administrative/general events and failed connections.

General workstations and servers:
Management and security events, logins and logouts both failed and successful, accounts created and deleted, should be logged from workstations and servers that do not directly support cardholder information. The Snare agents used for collection of such events should thus be configured to collect only those events to support this requirement. In other words, there is no need for process monitoring or file access auditing on these servers and workstations.

Servers and workstations used for storing and processing sensitive information:
All management and security events, logins and logouts both failed and successful, account created and deleted. Also, file auditing of the “/etc” directory on *Nix systems for creation or modification of files should be considered. On Windows and *Nix systems, full process event monitoring should be considered for the root/Administrator users. Care should be taken in employing file auditing
on Windows and *Nix systems, since this type of auditing can generate a large number of events. File auditing should thus be set on those specific directories that store cardholder information.
The Snare operating system agents can be set to file auditing using the micro web server provided with the agents.

The Snare Server will collect all events sent to it from the Snare agent and the SYSLOG nodes.
The following section details those reports in the Snare Server that should be monitored on a regular basis. The settings are the initial recommended settings, and should be fine-tuned once the Snare Server has been in operation for some time.

System Security Monitoring->Account Administration
Check for account creation. (Windows and Mainframe only). These objectives (for Windows mainly but also for ACF2/RACF Mainframe systems) should be checked at least once per week. They should be checked to ensure that only authorized staff have been creating or deleting Windows accounts. Also, the “Changes to Specified Groups” clonable objective should be used to monitor those Windows groups that are used for access to cardholder information.

System Security Monitoring->Login Activity (depending on the operating systems in use).
These objectives should be monitored, depending on the operating system in use at the particular agency. As a guide, the following objectives should be monitored on a weekly or daily basis, depending on the usefulness of reporting:

Failed Logins over a Threshold Value

Failed Logins per User for a Set Period

Failed Logins to Locked Accounts (Windows only)

Out of Hours Login Activity

Failed and Successful SU to ROOT (UNIX only)

System Security Monitoring->Sensitive Files and Resources
These objectives are operating system specific, and are clonable, which means that many objectives can be created to suit specific reporting requirements. If file auditing is required on those servers that process cardholder information, then the agent must be configured to send the file events to the Snare Server. Note: File auditing can generate an enormous amount of events, and so care must be taken to ensure that only those specific files and directories are audited. Check for creation or modification to the“/etc” directory by root or any other user on *Nix systems. On Windows and *Nix systems, check for process execution events by Administrator, root or equivalent users.

Network Event Analysis
Specific router and/or firewall events can be monitored via the objectives in the “Network Event Analysis” category. Almost all of these objectives contain clonable objectives, and so can be set to specifically monitor failed connections and management events.

Application Auditing->Dynamic Clonable Queries
The dynamic clonable queries allow a Snare Server administrator to monitor any data held in the Snare Server. They can, for example, be used to report on arbitrary logs sent to the Snare Server that may contain information required for reporting. Since the Snare Server can collect events from any source that is sent to it via UDP or TCP ports 6161, or UDP Port 514 (SYSLOG), reporting can then be undertaken based on the contents of these events.

Status and Statistics->Snare Health Checker
The Health Checker objective should be monitored daily to ensure the Snare Server is working optimally. This objective monitors all the key elements of the Snare Server, including the collection services, archival functions and agent reporting.

For our product sheet - > click here