Achieving Compliance with SNARE
SNARE is used by many large Defense, Aerospace, Intelligence, National Security and Defense Agencies, Energy and Utility, Finance and Insurance organizations to meet elements of federal and state security requirements, including: PCI, NISPOM and SCADA
In general, the broad requirements of PCI DSS are:
The Snare Server and agents, in combination, provide the capability to monitor user and system activity on your networks, and validate your access controls. In addition, network vulnerability assessment components can assist in the process of regularly testing your systems and networks for vulnerabilities which may affect PCI compliance.
Basic templates can be uploaded from the Snare Objective store (from the Snare Server navigate to System: Administrative Tools : Import Objectives). The objectives may then be configured to address PCI Data Security Standard requirements.
Please note that PCI 3.0 takes effect January 2015 and renders SNARE Open Source – non-PCI 3.0 Compliant. Why? More than half of the critical logs are not captured with SNARE Open Source, including: privileged user activity, system and group policy changes, DHCP logs, system time changes, host firewall policy changes and access logs, terminal service access and print logs.
NISPOM provides uniform policy guidance and requirements associated with the restrictions, requirements and other safeguards that are necessary to control, and prevent unauthorized disclosure of classified information released by U.S. Government Executive Branch Departments and Agencies to their contractors. NISPOM requires companies with facility security clearances to document various aspects of their security programs. The Snare Server provides a centralized collection, analysis, reporting and archival function for a variety of audit log sources, and is used by several organizations to meet federal guidelines associated with NISPOM – particularly the requirements stated in Chapter 8. On installation, the Snare Server runs a configuration wizard, which allows an administrator to install and configure objectives which are specifically targeted to address NISPOM Chapter 8 requirements. The following links provide more information on NISPOM Chapter 8
Key SNARE Server Reports: 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.
● Operating Systems Reports -> Administrative Activity
○ Monitor account creation related objectives for Windows and Mainframe systems. These objectives should be checked at least once per week. They should be checked to ensure that only authorized staff have been creating or deleting accounts.
○ Monitor objectives related to group modifications for those groups that are used to control access to sensitive information.
● Operating Systems Reports -> Login Activity
○ 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.
● Per user for a set period.
● To Locked Accounts (Windows).
■ Out of Hours Login Activity.
■ Failed and Successful SU to ROOT (Unix only).
● Operating Systems -> File and Resource Access / Process Execution
○ These objectives are operating system specific, and can be created to suit specific reporting requirements. In this case, the monitoring should be set so that access to specific directories is monitored, for those systems that contain sensitive information. The agent collection must be set so that file and directory access events are being collected for the server(s) in question.
○ 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 access to the “/etc” directory by root or any other user on *nix systems. On Windows systems, check for process execution events by Administrator or equivalent users.
● Network Reports
○ Specific router and/or firewall events can be monitored via the objectives in this category. Almost all of these objectives can be set to specifically monitor failed connections and management events.
● New Modular Objective Reports
○ If events are also being collected from a database or an application, and the SNARE Server does not have a specific template data source collection format available in which to store the incoming data, the events will be stored in the ‘Generic Log’ data source. Remember that the SNARE Server will collect any event that is sent to it via UDP or TCP ports 6161, or UDP Port 514 (SYSLOG).
○ If the SNARE Server does not have an existing pre-defined template objective to report on the particular events of interest, a new modular reporting objective, set to search the Generic Log data source, can be used to report on these events.
● Status Reports -> 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.
Supervisory Control And Data Acquisition (SCADA) networks contain computers and applications that perform key functions in providing essential services and commodities (e.g., electricity, natural gas, gasoline, water, waste treatment, transportation) to all Americans. As such, they are part of the nation’s critical infrastructure and require protection from a variety of threats that exist in cyber space today. By allowing the collection and analysis of data and control of equipment such as pumps and valves from remote locations, SCADA networks provide great efficiency and are widely used. However, they also present a security risk. As a result, almost every SCADA performs well. They’re reliable and flexible, but often lack security. The impairment of SCADA networks could cause interruption of critical services, process redirection, or manipulation of operational data that could have serious consequences.