InterSect [InterSect Swish]
Search Our Site
  Enter Search Terms

IAI is very proud to announce that Solutionary has selected Snare as their technology partner for the ActiveGUARD managed service platform.
InterSect Alliance International

As some are already aware, InterSect Alliance was recently purchased by Prophecy International, and is now InterSect Alliance International Pty Ltd. More good news to come.

Sarbanes-Oxley - Financial and Accounting Disclosure Information

The Sarbanes-Oxley Act, 30th July 2002, introduced legislative changes to financial practice and corporate governance regulations, that are designed "to protect investors by improving the accuracy and reliability of corporate disclosures made pursuant to the securities laws".

In order to adequately demonstrate regulatory compliance, it is recommended that organisations in the financial sector establish a comprehensive audit and event logging regime, across data stores, applications and operating systems.

The Snare Server, from InterSect Alliance, provides a centralised collection, analysis, reporting and archival function for a variety of audit log sources, and is used by several organisations to meet federal guidelines associated with Sarbanes-Oxley (SOX).

On installation, the Snare Server runs a configuration wizard, which allows an administrator to install and configure objectives which are specifically targeted to address Sarbanes-Oxley auditing requirements.

Sarbanes-Oxley 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 considered in conjunction with an agency's risk assessment and security policy.



(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 sections 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 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. However, the following ideas are presented as a guide as to how the Snare Server 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 (eg; 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.

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

    b. General workstations and servers:
    All management and security events, logins and logouts both failed and successful, account created and deletion 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.

    c. Servers used for key financial tasks:
    All management and security events, logins and logouts both failed and successful, account created and deletion. 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 either the graphical user interface or 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 server, then contact the team at InterSect Alliance to determine the most appropriate toolset to collect such logs. Note that the Snare Server 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 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.

    a. 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 authorised 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 financial information.

    b. 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)
  • Failed and Successful SU to ROOT (UNIX only)

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

    d. 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 objective contain clonable objectives, and so can be set to specifically monitor failed connections and management events.

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

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



    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; and

    This section of the SOX Act specifies that securities analysts be separated from the 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 the following Snare Server objectives could be used:

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

    b. System Security Monitoring->Process Monitoring.
    The same clonable objectives could also be set for process events. Process event monitoring allows a Snare Server administrator to monitor processes on the host(s) from which those type of events are being collected.

    c. Application Auditing->Dynamic Clonable Queries.
    If events are also being collected from a database or an application, and the Snare Server has not been designed to collect those events, then they will be placed in the “Generic Log” table. 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). The Dynamic Clonable Queries can then 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.


    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. The Snare Server will retain events in the database for a period defined by the Migration objective: Snare Server Utilities->Archival and Backup->Snare Data Migration (See the “Configure” tab for this objective). Once events are older then the period set in this objective, they will be migrated out of the database and onto disk in flat file, compressed form. They can then be copied onto CD or DVD via the objective: Snare Server Utilities->Archival and Backup->Interactive Data Archive. Should the events be required to be reviewed, they can then be loaded onto a forensic Snare Server using the objective Snare Server Utilities->Data Restoration->Snare Data Import. It is recommended that a Snare Server set in forensic mode be used to review old logs. The Snare Server can be placed in forensic mode via the the objective: Snare Server Utilities->Snare General Configuration Items.

    Snare provides a central collection, analysis, reporting and archival capability for a variety of operating systems, appliances, and servers, including:
    Windows NT/2000/XP/2003
    CISCO Routers / IOS
    CISCO 6500 Firewall
    CISCO Pix Firewall
    CyberGuard Firewall
    CheckPoint Firewall 1
    Gauntlet Firewall
    Netgear Firewall
    Netgear Router
    Netscreen Firewall
    Nortel VPN devices
    IPTables Firewall
    Microsoft ISA Server
    Microsoft IIS Server
    Microsoft FTP Server
    Microsoft Exchange Server
    Microsoft Chat Server
    Microsoft Proxy Server
    Point of Sale terminals (POS)
    Lotus Notes
    Snort NIDS
    IBM Socks Server
    Universal Log Format
    Generic Syslog Data
  • Snare Server
    With its' origins in open source software, the Snare Server from InterSect Alliance provides a central collection, analysis, reporting and archival tool for a very wide variety of log formats.

    Click here for more information
    Snare Demonstration

    Snare Introduction

    Snare Agents

    Snare Server
    Click on a video above, to find out more about Snare and to access the Snare Demonstration Server
    Copyright (c) 1999-2013 InterSect Alliance Pty Ltd