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.snaresolutions.com/compliance-2, as well as in dedicated White Papers.

Sarbanes-Oxley (SOX)

Sarbanes-Oxley (SOX) is an Act of the US Congress, designed to mandate specific controls over financial information. The implications for IT systems are more implied than specified, and are governed by the sections detailed below. The ideas presented below are provided as a guide, and should therefore be treated as guidance to be used in conjunction with an agency's risk assessment and security policy.

Section 404: Management Assessment of Internal Controls

SEC. 404. MANAGEMENT ASSESSMENT OF INTERNAL CONTROLS.

(a) RULES REQUIRED.—The Commission shall prescribe rules requiring each annual report required by section 13(a) or 15(d) of the Securities Exchange Act of 1934 (15 U.S.C. 78m or 78o(d)) to contain an internal control report, which shall—

(1) state the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting; and

(2) contain an assessment, as of the end of the most recent fiscal year of the issuer, of the effectiveness of the internal control structure and procedures of the issuer for financial reporting.

(b) INTERNAL CONTROL EVALUATION AND REPORTING.—With respect to the internal control assessment required by subsection (a), each registered public accounting firm that prepares or issues the audit report for the issuer shall attest to, and report on, the assessment made by the management of the issuer. An attestation made under this subsection shall be made in accordance with standards for attestation engagements issued or adopted by the Board. Any such attestation shall not be the subject of a separate engagement.

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

Those IT systems within an agency that do not directly support financial and/or audit functions should be monitored for general administrative activity. These systems may include devices and hosts such as network appliances (e.g. routers, firewalls), servers that provide secondary support functions such as DNS, print services, general file services, and workstations. Those servers and other hosts that are used to support key financial systems and applications should be closely monitored. In these instances, there will be additional event collection such as file auditing (to monitor key files and directories), and perhaps event collection from the financial database and/or custom applications that generate the audit events. These will be entirely dependent on the function of the server which may be hosting the financial application or data.

The following is therefore a recommendation on the events to be collected only from these nodes. Again, we do strongly recommend 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

All 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 financial activity. 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 Used for Key Financial Tasks

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 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. Snare Central will collect all events sent to it from the Snare Agent and the SYSLOG nodes.

Key Snare Central Reports

The following section details those reports in Snare Central that should be monitored on a regular basis. The settings are the initial recommended settings, and should be fine-tuned once 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 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 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 Snare Central will collect any event that is sent to it via UDP or TCP ports 6161, or UDP Port 514 (SYSLOG).
- If 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 Snare Central is working optimally. This objective monitors all the key elements of Snare Central, including the collection services, archival functions and agent reporting.

Section 501: Informational Partitions

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 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 Snare Central will collect any event that is sent to it via UDP or TCP ports 6161, or UDP Port 514 (SYSLOG).
- If 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.

Section 802: Record Retention

Section 802

§ 1520. Destruction of corporate audit records

(a)

(1) Any accountant who conducts an audit of an issuer of securities to which section 10A(a) of the Securities Exchange Act of 1934 (15 U.S.C. 78j–1(a)) applies, shall maintain all audit or review workpapers for a period of 5 years from the end of the fiscal period in which the audit or review was concluded.

(2) The Securities and Exchange Commission shall promulgate, within 180 days, after adequate notice and an opportunity for comment, such rules and regulations, as are reasonably necessary, relating to the retention of relevant records such as workpapers, documents that form the basis of an audit or review, memoranda, correspondence, communications, other documents, and records (including electronic records) which are created, sent, or received in connection with an audit or review and contain conclusions, opinions, analyses, or financial data relating to such an audit or review, which is conducted by any accountant who conducts an audit of an issuer of securities to which section 10A(a) of the Securities Exchange Act of 1934 (15 U.S.C. 78j–1(a)) applies. The Commission may, from time to time, amend or supplement the rules and regulations that it is required to promulgate under this section, after adequate notice and an opportunity for comment, in order to ensure that such rules and regulations adequately comport with the purposes of this section.

This section is quite clear on the retention of data. 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).

Once events are older than the period set in this objective, they will be migrated out of the database and onto either optical media, or external storage, in a compressed flat file form. Should the events be required to be reviewed, they can then be loaded onto a forensic Snare Central using the objective System -> Data Restore -> Snare Data Import.

National Industrial Security Program – Operating Manual (NISPOM)

The National Industrial Security Program – Operating Manual (NISPOM), is a US DoD manual which details the security requirements for those companies and agencies which participate in the DoD Industrial Security Program. The following IT event collection and analysis requirements have been derived from the NISPOM and are reproduced by the sections detailed below. The ideas presented below are provided as a guide, and should therefore be treated as guidance to be used in conjunction with an agency's risk assessment and security policy. The NISPOM handbook is available from the website: http://www.dss.mil/isec/nispom.htm

This section contains some ideas on establishing appropriate event logging controls that would be consistent with NISPOM compliance. Of note: it is very important that an organizational risk assessment and IT security policy be used to ensure they are the key drivers for NISPOM compliance. The US DoD Accreditation Authority has the final say on specific compliance objectives.

Section 8-602: Audit Capability

8-602. Audit Capability. Security auditing involves recognizing, recording, storing, and analyzing information related to security-relevant activities. The audit records can be used to determine which activities occurred and which user or process was responsible for them.

a. Audit 1 Requirements

(1) Automated Audit Trail Creation: The system shall automatically create and maintain an audit trail or log (On a PL-1 system only: In the event that the Operating System cannot provide an automated audit capability, an alternative method of accountability for user activities on the system shall be developed and documented.) Audit records shall be created to record the following:

(a) Enough information to determine the date and time of action (e.g., common network time), the system locale of the action, the system entity that initiated or completed the action, the resources involved, and the action involved.

(b) Successful and unsuccessful logons and logoffs.

(c) Successful and unsuccessful accesses to security-relevant objects and directories, including creation, open, close, modification, and deletion.

(d) Changes in user authenticators.

(e) The blocking or blacklisting of a user ID, terminal, or access port and the reason for the action.

(f) Denial of access resulting from an excessive number of unsuccessful logon attempts

(2) Audit Trail Protection. The contents of audit trails shall be protected against unauthorized access, modification, or deletion.

(3) Audit Trail Analysis. Audit analysis and reporting shall be scheduled, and performed. Security relevant events shall be documented and reported. The frequency of the review shall be at least weekly and shall be documented in the SSP.

(4) Audit Record Retention. Audit records shall be retained for at least one review cycle or as required by the CSA.

b. Audit 2 Requirements. In addition to Audit 1:

(1) Individual accountability (i.e., unique identification of each user and association of that identity with all auditable actions taken by that individual). Periodic testing by the ISSO or ISSM of the security posture of the IS

c. Audit 3 Requirements. In addition to Audit 2:

(1) Automated Audit Analysis. Audit analysis and reporting using automated tools shall be scheduled and performed.

d. Audit 4 Requirements. In addition to Audit 3:

(1) An audit trail, created and maintained by the IS, that is capable of recording changes to mechanism's list of user formal access permissions.

The intent of the above section of the NISPOM is to ensure that controls are in place to safeguard sensitive DoD information. 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 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.

Those IT systems within an accredited network that do not directly support the security of information (such as DNS servers, perhaps), may not be required to be audited to the extent detailed in Paragraph 8-602. Please check with your accreditation authority. The following is therefore a recommendation on the events to be collected only from specific servers and/or workstations. Again, we do strongly recommend that this collection profile be guided by the outcomes of an agency's risk assessment and security policy.

Network Devices

General Workstations and Servers

All 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 sensitive 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, accounts created and deleted. Also, file auditing of the "/etc" directory on *nix systems should be considered. On Windows systems, full process event monitoring should be considered. 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 sensitive information. The Snare Operating System Agents can be set to file auditing using the micro web server provided with the agents.

Key Snare Central Reports

Snare Central will collect all events sent to it from the Snare Agent and the SYSLOG nodes. The following section details those reports in Snare Central that should be monitored on a regular basis. The settings are the initial recommended settings, and should be fine-tuned once 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 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 Snare Central will collect any event that is sent to it via UDP or TCP ports 6161, or UDP Port 514 (SYSLOG).
- If 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 Snare Central is working optimally. This objective monitors all the key elements of Snare Central, including the collection services, archival functions and agent reporting.

PCI/DSS Compliance

The Payment Card Industry Data Security Standard (PCI DSS), is a security standard developed by selected companies covering detailed security requirements for protection of credit card information and client details. The following IT event collection and analysis requirements have been derived from the PCI DSS and are reproduced by the sections detailed below. The ideas presented below are provided as a guide, and should therefore be treated as guidance to be used in conjunction with an agency's risk assessment and security policy.
The Payment Card Industry Data Security Standard (PCI_DSS) Version 2.0 Release: October, 2010 PCI DSS is available from the website: https://www.pcisecuritystandards.org/security_standards/documents.php

From the document:

"The PCI DSS security requirements apply to all system components.In the context of PCI DSS, system components are defined as any network component, server, or application that is included in or connected to the cardholder data environment. System components also include any virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors. The cardholder data environment is comprised of people, processes and technology that store, process or transmit cardholder data or sensitive authentication data. Network components include but are not limited to firewalls, switches, routers, wireless access points, network appliances, and other security appliances. Server types include, but are not limited to the following: web, application, database, authentication, mail, proxy, network time protocol (NTP), and domain name server (DNS). Applications include all purchased and custom applications, including internal and external (for example, Internet) applications.".

PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply.

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:

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

Browser not supported