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

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.

C.2 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; 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.

C.3 SECTION 802: RECORD RETENTION

1520. Destruction of corporate audit records

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