...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
Additional Information
InterSect Alliance provides detailed implementation guides for several major national, international, and industry-specific security frameworks.
...
https://www.intersectalliance.com/strategic-issues/security-regulations/
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.
| Info |
|---|
Section 404: Management Assessment of Internal ControlsSEC. 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 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 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.
Key Snare Central Reports
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).
- Failed Logins
- 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:
- 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;" |
...
- 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.
Section 802: Record Retention
| Info |
|---|
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. |
...
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
| Info |
|---|
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. |
...
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
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 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
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).
- Failed Logins
- 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:
- 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.
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
...
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.
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.