infrastructure is being used in addition to its relationship to its support role in financial reporting.
esting information technology infrastructure is the broadest area of SOX audits. The security of these systems will be the focus of most of your testing. The security profile includes systems availability, data integrity, and accountability. What components must be tested may include more than what the initial risk analysis encompassed. Although specific components of IT infrastructure such as applications, operating systems and hardware supporting the financial reporting function were identified, you will find that much of your perimeter infrastructure which protects your internal network(s) will be involved in the testing also.
Logical access to systems is usually tested quite thoroughly. This includes the process of creating and maintaining user accounts, remote access, and perimeter security.
Network documentation including network diagrams, general security policies, operations procedures, and backup and recovery policies will be evaluated too.
Anti-virus, patch management and outside/internal threat prevention measures in place will also be examined.
Segregation of duties among the IT staff will also be a consideration in terms of accountability and fraud controls.
The amount of detailed testing required for these components will to a great extent depend upon how they are used. Factors such as internet access, remote access and extranets will have a good deal to do with determining the extent of testing. Commonly, perimeter testing will include firewalls, and remote access configurations. The audits usually are not full blown security audits with penetration tests and detailed work programs. Should weakness or deficiencies be found however, testing could escalate to a more detail as compensating controls are assessed. But again there is a
Chapter
12
T
K E Y T O P I C S
Security
Accountability
Availability
Integrity
caveat. If your business is e-commerce it may be necessary to conduct a more detailed audit. If the business provides remote access to enter financial information into company systems more detailed testing of security settings might be in order. It all depends on how the infrastructure is being used and the risks associated with that use.
User Accounts Management
Who has access to your infrastructure and what level of permissions they have to these components is of primary importance in compliance testing.
Testing controls related to user account management will most surely be conducted at all companies. This is a general control that is always identified as a key control. IT is responsible for certain portions of user account setup and maintenance. Those are the elements that will be tested for compliance.
A documented policy needs to exist for this control which details the rules and procedures involved in user account management for both internal and remote access.
Ultimately it is the data owners and business managers who initiate the process of setting up new user accounts by making a formal request to IT and therefore responsible for this function. IT however is also responsible for seeing to it that the account is setup properly.
Testing of this control will require examination of a sample of documented requests for access and examination of the access granted by IT. What was requested is either verified or not.
The same will occur for requests for changes to user access levels.
Essentially there should be a clear audit trail regarding any activity having to do with user account management.
The process for changes and updates to user account permissions, group assignments, promotions/transfers and terminations are all part of the maintenance of user accounts and need to be documented.
Testing of these controls will be straight forward. Lists of user accounts will be obtained from IT and lists of employees active and terminated will be obtained from HR. Samples from the two lists will be compared to determine the following:
Are there terminated employees who still have active user accounts in the network or in other applications?
If there are terminated employees present what was the last login date for that account? Is the last login date before or on the day the employee left the company or after?
Are there user accounts which are categorized as orphans? (not active not on terminated list)
Are there vendor or contractor accounts that are active?
If group profiles are used do the samples verify users are in appropriate groups based on job description and authorization?
Are access rights associated with group profiles clearly understood by IT staff and business management?
User with accounts that permit remote access to company systems will also be tested using the same criteria as above.
Testing user accounts of applications specific to IT use such as firewalls, IDS systems, backup systems, servers, change management systems, version control systems and code libraries, routers and operating systems may also be conducted if the risk assessment calls for it.
Permission levels will be examined for samples of accounts in these systems and the same criteria noted above will be used to assess access security.
Also related to these controls is another control which requires that all user accounts in all identified systems be reviewed periodically for relevancy and appropriateness. Changes that result from annual reviews of user access would show a weakness in the control design. Somewhere along the line of IT and Business Management/Human Resources the process is not working.
Managing user account access is a difficult job when done manually. Most companies have exceptions found during testing. (An exception is an audit term used to describe a control deficiency.)
The more automated you can make the process the better. If you have a great deal of changes (daily) or high turnover of employees you should consider implementing an automated user account management system. There are many good tools designed to manage user account access more efficiently. Research into these tools is necessary to determine if they can improve your situation.
Automating this function will most likely reduce auditing fees for future audits.
Vulnerability Scanners
Manual testing of security settings for operating systems and databases can be time consuming and expensive. Automated testing can help reduce time spent and thus decrease costs.
Vulnerability scanners are handy automated security settings detectors and evaluation engines that can be used to identify security weaknesses/strengths in operating systems and databases. These automated tools can provide documented evidence of the security control settings in place. Scanning can also be used on an ongoing basis as an automated control which can produce sound documented compliance evidence in the form of reports.
There are many vulnerability scanners for both databases and operating systems available in the marketplace. Some are good and some not so good. Select one that addresses all of your operating systems and database types in one package if you can.
Some of these products have been designed to scan for the common security settings that a SOX audit addresses and automatically evaluate the strength of configuration. These include patch levels, password policies, weak passwords, non-compliance issues and other areas of weakness.
Event Logging and Monitoring
Implementing a robust logging/auditing function within all the companies’ servers’ sounds appealing in terms of internal control the truth is that logging all activities on a busy network is not feasible for most companies.
However, auditing should be enabled on all of your key systems to some degree. Restrict what events you will audit. In addition evidence needs to be provided which shows someone is reviewing these logs. This may not be the most efficient way of monitoring. But in order for the control to be valid it is one which needs a review element as part of its design.
Another option to logging/auditing and review would be an alert system that logs the same information but doesn’t retain the data in huge log files. Security violation notices that are detected by these systems are turned into email alerts and sent to appropriate individuals in real time which makes the control a preventive one. As mentioned earlier in the discussion of control design, preventive controls are the most desirable.
A combination of the two technologies may be the more reasonable design for this type of control.
The types of events and activities that may need to be audited/logged include the following:
DBA, Network Administrator and other high privileged user accounts.
Various user access violations considered high risk
New User Account Setups
Threat factors
The best way to describe the threat factors used in conducting a SOX audit is that external threats are for the most part generic threat risks that apply to all companies. An internal threat usually means employees.
Hacking systems, releasing malicious code, destroying data are the threats posed by individuals both externally and internally.
For the most part it seems that SOX audits are more concerned with internal threats. In most cases perimeter security is tested less stringently than network security.
But again that is not always the case. If a company lacks a firewall for instance then more detailed testing of perimeter security would be in order.
Common internal threats are programmers with writer access to production systems, IT people with administrative access, disgruntled employees and accidents.
It is important that the permissions granted on your systems to IT staff and all employees, contractors and vendors be based on the principle of “least privilege” and appropriate to the job description. Excessive permissions without business reason are considered a deficiency.
Perimeter security
If you company allows no access to the internet and is a completely closed system, perimeter security would be considered low risk. Most companies are not like that.
At a minimum a company should have a firewall. For a low risk situation just a packet filtering router or two would be sufficient but just barely.
Modems should be kept to a minimum or done away with altogether in favor of a VPN or some other means of remote access that doesn’t require connecting to a modem.
What ever is used should have strong authentication capabilities which utilize recognized security standards.
The firewall rule base will probably be reviewed along with encryption methods used in remote access.
Preventive controls such as virus and malicious code scanners that prevent these objects from entering your internal network are a good idea and strengthen your security profile. Most email systems offer that capability to a limited extent.
Internally you will need to show you have virus and programmed threat protection running on the networks.
If the nature of the business is e-commerce or other high risk activity be prepared to have more detailed testing conducted.
Firewalls, routers, operating systems supporting them will then be tested more thoroughly. The security settings, access controls and configuration management of these components will be the focus.