Versions Compared

Version Old Version 2 New Version Current
Changes made by

maria ieropoulos

Leigh Purdie (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Additional Information

InterSect Alliance provides detailed implementation guides for several major national, international, and industry-specific security frameworks.

...

  More information is available from the web site

...

at https://www.intersectalliance.com/strategic-issues/security-regulations/

...

The intent of the above section of the Act is to ensure that controls are in place to safeguard the financial reporting components of an agency, and an assessment is made in relation to the effectiveness of the controls. The Snare Central 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. However, the following ideas are presented as a guide as to how the Snare Central can be configured to meet the basic guidelines of the Sarbanes-Oxley Paragraph 404 requirements. It is strongly recommended that these ideas be reviewed against the specific requirements of an agency.

...

All management and security events, logins and logouts both failed and successful, accounts created and deleted. Also, file auditing and process event monitoring should be considered on those directories that store financial reports. Care should be taken in employing file auditing, since this type of auditing can generate a large number of events. File auditing should thus be set on those specific directories that store financial reports. The Snare Operating System Agents can be set to file auditing using the micro web server provided with the agents. Financial database and/or custom applications will usually create log files of those users that have accessed data. These logs types should be considered for collection. If there is no SYSLOG or other facility enabled to send the events to a Snare Central, then contact your Snare Central support team to determine the most appropriate tool-set to collect such logs.
Note that the Snare Central will automatically collect any events sent to it either via UDP/TCP Port 6161 or via SYSLOG Port UDP 514. Events collected in this manner will be stored in the "Generic Log" table. The Snare Central will collect all events sent to it from the Snare Agent and the SYSLOG nodes.

...

The following section details those reports in the Snare Central that should be monitored on a regular basis. The settings are the initial recommended settings, and should be fine-tuned once the Snare Central has been in operation for some time.

  • Reports -> Operating Systems -> 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 financial information.
  • Reports -> Operating Systems -> 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).
  • Reports -> Operating Systems -> File and Resource Access
    • These objectives are operating system specific, and can be created to suit specific reporting requirements. If file auditing is required on those servers that process financial information, then the agent must be configured to send the file events to the Snare Central.
    • 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.
  • Reports -> Network
    • 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
    • If events are also being collected from a database or an application, and the Snare Central 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 Central will collect any event that is sent to it via UDP or TCP ports 6161, or UDP Port 514 (SYSLOG).
    • If the Snare Central 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 -> Snare Health Checker
    • The Health Checker objective should be monitored daily to ensure the Snare Central is working optimally. This objective monitors all the key elements of the Snare Central, including the collection services, archival functions and agent reporting.

Section 501: Informational Partitions

...


Info

SEC. 501. TREATMENT OF SECURITIES ANALYSTS BY REGISTERED SECURITIES ASSOCIATIONS AND NATIONAL SECURITIES EXCHANGES.

501(a)(3) ''(3) to establish structural and institutional safeguards within registered brokers or dealers to assure that securities analysts are separated by appropriate informational partitions within the firm from the review, pressure, or oversight of those whose involvement in investment banking activities might potentially bias their judgment or supervision;"

 


This section of the SOX Act specifies that securities analysts be separated from investment banking activities. This requirement will clearly be agency specific, and therefore the requirement for event monitoring will vary greatly on the functions of the agency. It is therefore recommended that the data owner be consulted as to which resources mandate that the separation be enacted. If, for example, certain directories need to be excluded to a certain group or individual, then the appropriate access controls should be set and event monitoring be set to ensure those users have not accessed the resources. In the case of file and/or directory access, the following Snare Central objectives could be used:

  • Reports -> Operating Systems -> File and Resource Access
    • 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 only for those users that are not allowed to view files within those directories. The agent collection must be set so that file and directory access events are being collected for the server(s) in question.
  • Reports -> Operating Systems -> Process Monitoring
    • Process event monitoring allows a Snare Central administrator to monitor processes on the host(s) from which those types of events are being collected.
  • New modular objective
    • If events are also being collected from a database or an application, and the Snare Central 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 Central will collect any event that is sent to it via UDP or TCP ports 6161, or UDP Port 514 (SYSLOG).
    • If the Snare Central 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, and specifically, those users that are allowed or not allowed to have access to the application or database.

...

This section is quite clear on the retention of data. The Snare Central will retain events in the database for a period defined by the Migration objective, if removal has been configured: System -> Data Backup -> Data Backup (See the "Configure" tab for this objective).

...

The intent of the above section of the NISPOM is to ensure that controls are in place to safeguard sensitive DoD information. The Snare Central 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. However, the following ideas are presented as a guide as to how the Snare Central can be configured to meet the basic guidelines of the NISPOM Paragraph 8-602 requirements. It is strongly recommended that these ideas be reviewed against the specific requirements of an agency.

...

Key Snare Central Reports

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

  • Reports -> Operating Systems -> 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.
  • Reports -> Operating Systems -> 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).
  • Reports -> 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.
  • Reports -> Network
    • 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
    • If events are also being collected from a database or an application, and the Snare Central 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 Central will collect any event that is sent to it via UDP or TCP ports 6161, or UDP Port 514 (SYSLOG).
    • If the Snare Central 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 -> Snare Health Checker
    • The Health Checker objective should be monitored daily to ensure the Snare Central is working optimally. This objective monitors all the key elements of the Snare Central, including the collection services, archival functions and agent reporting.

...

Audit logging capabilities underpin a range of security measures within PCI/DSS, however section 10 of the document specifically addresses logging and auditing. Requirement 10 is reproduced below for reference:

Info

Requirement 10: Track and monitor all access to network resources and cardholder data.
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.


10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.

10.2 Implement automated audit trails for all system components to reconstruct the following events:

10.2.1 All individual user accesses to cardholder data

10.2.2 All actions taken by any individual with root or administrative privileges

10.2.3 Access to all audit trails

10.2.4 Invalid logical access attempts

10.2 5 Use of identification and authentication mechanisms

10.2.6 Initialization of the audit logs

10.2.7 Creation and deletion of system-level objects.

10.3 Record at least the following audit trail entries for all system components for each event:

10.3.1 User identification

10.3.2 Type of event

10.3.3 Date and time

10.3.4 Success or failure indication

10.3.5 Origination of event

10.3.6 Identity or name of affected data, system component, or resource.

10.4 Using time synchronization technology, synchronize all critical system clocks and times and ensure that the following is implemented for acquiring, distributing, and storing time. 

10.4.1 Critical systems have the correct and consistent time. 

10.4.2 Time data is protected

10.4.3 Time settings are received from industry-accepted time sources.

10.5 Secure audit trails so they cannot be altered.

10.5.1 Limit viewing of audit trails to those with a job-related need

10.5.2 Protect audit trail files from unauthorized modifications

10.5.3 Promptly back-up audit trail files to a centralized log server or media that is difficult to alter

10.5.4 Write logs for external-facing technologies onto a log server on the internal LAN.

10.5.5 Use file integrity monitoring or change detection software to ensure that existing log data cannot be changed without generating alerts (although new data being added should not cause an alert).

10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion detection system (IDS) and authentication, authorisation, and accounting protocol (AAA) servers (for example, RADIUS).10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from back-up).

 

Snare Central and Agent Settings for PCI DSS

The intent of the above section of the PCI DSS is to ensure that controls are in place to safeguard cardholder information. The Snare Central 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. See our regulatory compliance document on the InterSect Alliance web page, as highlighted in "Additional Information" above, for ideas and as a guide as to how the Snare Central can be configured to meet the basic guidelines of the PCI DSS section 10 requirements. It is strongly recommended that these ideas be reviewed against the specific requirements of an organisation.