Audit Management Planning

 < Day Day Up > 



Audit management planning is the initial step for an audit. This process defines the understanding of the objectives to be accomplished by the audit, assigning the appropriate number of trained employees, obtaining the background information, understanding the legal obligations, performing analytical review procedures, and identifying the areas of risk in the audit. Here are the major steps of an IT audit:

  • Preliminary audit work

  • Obtain understanding of control structure

  • Assess control risks

  • Controls testing

  • Form audit opinion and issue report

Audit Risk

Auditors must make judgments on the acceptable levels of audit risk. It is important to remember that the levels of risk will vary across the different segments of the audit, as there are systems that are more susceptible to errors, ineffectiveness, inefficiencies, and fraud.

Experience Note 

As unpopular as it is to say, there is a school of thought that equates audit "irregularities" with fraud. Fraud is when a person lies to obtain money or something of value and obtains it.

An example of different types of risks associated with different segments of the audit, systems involving handling of cash are very susceptible to theft, where data processing systems are usually susceptible to inefficient resource allocation. In planning to manage audits, the most difficult judgment is the level of acceptable risk relevant to each audit segment. It is for this reason that auditors should be knowledgeable and experienced persons. Auditors must understand the control environment and the associated risks by examining management and application controls already in place. For example, when auditors review system development activities, they are seeking to understand the controls that are associated with these tasks.

They attempt to understand the business processes, including components such as human expertise, information technology, communications, management controls and application controls so they can assess related vulnerabilities and attendant risks. By understanding processes, components, behavior, and intended results, auditors can provide appropriate safeguard recommendations, if any apply.

Planning the Audit

In order to conduct an audit properly, a comprehensive audit management plan must be crafted.

Experience Note 

If you do not plan, you are planning to fail.

The audit management plan should be action oriented, by listing the primary objectives to be performed. It should be tailored to the specific targeted business unit or division.

In drafting the audit management plan, a thorough review must be made of the organization's policies, with particular attention paid to risk management activities.

Experience Note 

There is some confusing terminology that should be clarified here. The purpose of integrated critical incident management is the continuation of profitable operations before business-harmful events happen. It is a wise business decision to take a proactive approach to critical incident management so risk management policies and procedures are designed and implemented. In essence, risk management is a series of steps where critical assets, including human resources, data, and facilities required to maintain profitability are identified and prioritized. Critical asset threats and their frequency, vulnerabilities, and existing safeguards are identified. In the event of a critical incident, meaning an incident affecting critical assets and profitability occurs, the organization has disaster recovery procedures in place to recover critical assets. As soon as critical assets are recovered, the process of planned business resumption takes place. In this phase, basically the business is returned to normal operating stature.

In the crafting, development, and implementation of policies, procedures, and standards, the organization is providing a process governing the activities of its employees consistent with the particular organization's goals and objectives. In many cases there are laws, regulations, and requirements affecting how the organization must conduct all or part of their business processes. Risk management is an integral part of the policy and procedure implementation. Auditing is basically an impartial review and investigation into the application of the organization's policies, procedures, and standards.

In crafting the audit management plan, the organization's strategic plan and objectives should be reviewed. This is essentially the basic guiding documentation for the organization. Depending on the business' units that are being audited, their applicable policies, procedures, and standards should be carefully reviewed. Job descriptions, organizational charts, lines of reporting, lines of authority, and chains of command should be made part of the information cache used to form the basis of the audit management plan.

In some business environments, audit management planning requires the auditors to conduct a preliminary survey through questionnaires to establish the appropriate scope addressing relevant business risks, develop the audit management plan, and direct auditor activities within the audit program. Often senior audit managers prepare questionnaires, also known as interrogatories, and send them to appropriate senior managers of the audit target. When completed, these questionnaires will provide the auditors with comprehensive visibility into the processes of the business unit.

These questionnaires may help auditors identify critical areas on which they need to focus their attention rather than taking a scattered, "shotgun" approach. As part of this preliminary questionnaire survey, auditors should review systems and processes to identify key controls already in place.

General questions that should be asked in preparing audit management plan questionnaires include but not limited to:

  • What are the critical issues regarding this business unit's operation?

  • What are the critical assets of this business unit?

  • What are the critical management functions?

  • What are the critical applications?

  • Does this business unit process sensitive data?

  • What are the risks to the business unit?

  • What substantive steps have been taken to address these risks?

  • What processes are least tested in the unit's business unit's daily operations? For example, if the business unit suffers from frequent power-outages and uses emergency power sources, including uninterruptible power sources and emergency generators, to restore operations, then power recovery requirements are likely to be well-formulated and tested. However, in the case of a complete disaster recovery plan, it may not be tested, and in fact, may not exist at all. The audit management plan should be the governing document for the "biggest bang for the buck."

Another valuable source in the development of an audit management plan is the review of previously performed audit reports. Many times these documents will identify potential weaknesses that should have been corrected or addressed earlier. The audit management plan is merely that, an activity plan. It should address those areas to be evaluated, and not too much more. Audit programs are different from audit plans in that they are comprehensive documents delving into the audit's "nuts and bolts."

Experience Note 

Audit management plans are considered part of the auditor's work papers and must be retained. Their absence is considered a lack of professional due diligence or even evidence destruction.

Exhibit 7 is a brief example of an audit management plan.

Exhibit 7: Audit Management Plan for Firewall Administration Unit

start example

Audit Step

Planning

  1. Discuss nature and scope of audit with key senior personnel

  2. Discuss audit requirements with senior managers

  3. Assemble required audit staff and build team

  4. Draft comprehensive audit program

  5. Draft initial budget

Reporting

  1. Hold opening meeting with appropriate personnel at initiation of audit

  2. Use standard audit reports format including compilation of audit findings and recommendations

  3. Hold closing meeting with key managers to review draft of final audit report

  4. Identify key senior managers in the event of reporting irregularities before audit conclusion

Preliminary Audit Steps

  1. Identify key employee contacts for audit

  2. Obtain appropriate organization and business unit documentation including

    1. Strategic business plans

    2. Relevant policies, procedures, and standards for firewall administration unit

    3. Relevant documentation to gain an understanding of the operations of the firewall administration unit

Audit Procedures

  1. Understand unit's business practices and compare with organization's policies, practices, and standards

  2. Understand and document business process flows

  3. Interview pertinent employees in firewall administration unit to gain an understanding of their functions, risks, and other relevant issues

Testing

  1. Testing will be performed to increase auditor's understanding of the firewall administration unit's function and activities

  2. Testing will increase the auditor's understanding of managerial and application controls

  3. Auditor will test if relevant controls are operating correctly and consistently

  4. Auditor will test metrics to manage firewall administration

  5. Auditor will test the correct design, development, and implementation of firewall administration

end example

Audit Programs

Audit programs are guides specifically directing auditors' activities.

Experience Note 

Although there are procedures for auditing, none are so restrictive that auditors cannot review areas outside the audit program with sufficient logical justification. Auditors have found fraud by going outside their audit program, looking in the company parking lot and asking why the accounts payable clerk is driving an expensive luxury car.

The audit program is a comprehensive, detailed document addressing the relevant audit areas, and in some cases, the methodology of the audit. It is an action-oriented document, with much more detail than the audit plan. An audit program has the following purposes:

  • Provides detailed communications to the intended recipients and audit team members of the audit objectives

  • Facilitates direction, scope, and control over the audit process; directs team members having specialized skills and knowledge to specific areas

  • Delivers a record of the audit process

  • Directs the collection of evidence in specific areas

  • Suggests the sampling methodology to be used in specific audit areas

  • Documents the professional due diligence of the audit process, including planning, fieldwork, and supervision

  • Becomes included in the auditors' work papers and is thereby maintained for future review

  • In some cases, it documents specific audit assignments

Standard Audit Programs

There are several standard security assessment or audit programs. There are certain advantages for auditors to use one of the standard audit programs:

  • They usually have a history of successful engagements and results.

  • They frequently have been adopted by industries as governing instruments.

  • They may save a significant amount of auditor resources by suggesting business operations to be tested.

One of the most comprehensive standard information technology programs is the COBIT program. The Information Systems Audit and Control Association (ISACA, www.isaca.org) developed this program. It is a generally applicable and accepted standard for information and information technology control. COBIT is fully adaptable and applicable for enterprise-level and smaller organization information technology areas. It starts from a control framework, it is management oriented, and it is based on critical review of tasks and activities regarding business operations.

COBIT deals with three levels:

  1. Domain. This is a natural grouping of processes, often matching an organizational domain of responsibility.

  2. Processes. This is a series of jointed activities with natural breaks.

  3. Activities. Actions needed to achieve a measurable result. Activities have a life cycle where tasks are discreet.

Control objectives domains are divided into four areas:

  1. Planning and organization

  2. Acquisition and implementation

  3. Delivery and support

  4. Monitoring

One of the more-popular security guidance standards is BS 7799, a British Standard Institute program publication. It was submitted to the International Standards Organization who published it as the Code of Practice for Information Security Management and was subsequently published by ISO under the number 17799 in 2000. [2]

The stated purpose of 17799:2000 is to

give recommendations for information security management for use by those who are responsible for initiating, implementing or maintaining security in their organization. It is intended to provide a common basis for developing organizational security standards and effective security management practice and to provide confidence in inter-organizational dealings.

ISO 17799 is a general organizational management and best practices guide intended to deliver secure system operations. It is not applicable to all organizations and does not attempt to address all required internal controls. It generally covers the following areas:

  • Policies

  • Security architecture

  • Information controls

  • Human resources

  • Physical security matters

  • Access control

  • Business continuity procedures

The United States government through the National Institute for Standards and Technology (NIST, www.nist.gov) has several high-quality guidance publications relevant to security practices in information technology systems:

  • Generally Accepted Principles and Practices for Security Information Technology Systems

  • Security Issues in the Database Language SQL

  • Computer Security

  • Guidelines for Automatic Data Processing Physical Security and Risk Management

  • Guide for Developing Security Plans for Information Technology Systems

  • Engineering Principles for Information Technology Security

These U.S. government documents are general and high-level documents adaptable to most organizational structures and functions. They can provide auditors with a variety of domains that should be considered when developing audit plans and programs.

Developing Your Audit Program

Developing proprietary audit programs is one of the challenges facing audit managers. There are several sources that should influence the program that will be designed by the audit manager and her team. Logically, the first place to begin is with the organization's risk management program. Attention should be paid to the structure and details encompassed in this document. Audit managers crafting their audit plan should see if the organization's critical assets have been identified, prioritized, and classified relative to their sensitivity and their criticality. They should also look to see if the organization has detailed relevant threats, their likelihood of occurrence, and systems vulnerabilities with accompanying safeguards.

Experience Note 

When critical asset safeguards are considered, it is important to place them in the context of cost/benefit. Do not protect junk!

It is very likely that pursuant to the risk management program, critical assets were divided into relevant pillars such as human resources, data, and physical facilities. The structure of the risk program may easily serve as one of the supporting documents of the audit program.

Audit managers and their teams are going to thoroughly review the organization's policies, procedures, and standards ascertaining if they address potential risks facing the business. From their review, the audit team will design their audit program. The program will have divided the organization's policies, procedures, and standards according to their relevance to the audit. It will also have determined the applicability of any laws and regulations and test to ascertain if they are being observed by the organization.

The organization's policies and procedures should be broken into the basic elements, and from there the audit program is drafted. For example, the organization has a policy governing the method that packet screen firewalls are going to be deployed on the network's perimeter and this policy states that there is an access control list for permissible computer traffic. The auditors should review this policy to determine the specific elements of permissible traffic. They should query the systems administrators to determine the appropriate protocols, e.g., FTP, POP3, DNS, etc. Audit managers will design their audit program to include sampling and testing those policies and relevant documentation. Included in the audit program will be all facets of firewall operation, development under the SDLC, and effectiveness. Connected to the firewall audit is a review of all aspects surrounding the management, selection, training, and deployment of firewall administrators.

Designing the audit program from the organization's operations, policies, procedures, and standards is the most effective means of completing a meaningful audit; however, it is probably the most time consuming. This means of crafting an audit program can be tedious and challenging but the resulting program, if skillfully done, will likely result in an on-target and highly effective audit report.

It is prudent for auditors to review and know the target's business operations, hardware, operating systems and applications so they may determine if updating and change management controls have been implemented in a timely and correct fashion.

Gaps, meaning areas of risk not addressed by existing policies and procedures, or policies and procedures that go unnoticed by employees, must be reported as findings in the audit report. For this reason it is imperative that the audit team be composed of broadly experienced individuals that will recognize and credibly articulate their findings.

Useful Internet Web Sites

Fruitful areas for drafting audit programs may be found at these Web sites:

  • www.cert.org

  • www.sans.org

  • www.cve.mitre.org

  • http://icat.nist.gov

  • http://www.securityfocus.com

These sites present the most-common system vulnerabilities and exploits (CVEs). Their purpose is the orientation of system managers and auditors in determining if their systems contain common security flaws and provide means addressing them. There are comprehensive lists, published by the above institutions, detailing commonly occurring system vulnerabilities. Some are named the "Ten Most Critical Vulnerabilities" or the "Twenty Most Critical Vulnerabilities." Regardless, they list the most commonly found vulnerabilities based primarily on surveyed systems administrators, security officers, or auditors. Many businesses use their lists to prioritize their efforts so the most commonly occurring risks are addressed first. They provide a basis of commonly exploitable system flaws allowing auditors to direct their efforts in these areas first with the prevailing logic being that these vulnerabilities comprise the majority of successful system attacks.

Common Attacks

Most attackers are opportunists who take advantage of the easiest and most convenient attack route. Commonly, attackers attempt to gain access through the best-known system flaws with readily available tools from the Internet. Because they count on organizations failing to address their system risks, attackers identify flawed systems and attack them using commonly known exploits. It is for these reasons that auditors may wish to pay particular attention to these vulnerability lists as the first place to concentrate their efforts.

Flawed Systems

There are many reasons for flawed systems. Auditors should be aware that some operating systems and applications were not initially designed as production software. Such was the case with UNIX. Over the past twenty years, it has been pinched, tweaked, and patched until we have the platform we have today. After all this development, you would naturally think UNIX and its accompanying applications are perfect. No, they're not.

Other programs are rushed to market with such speed; there was insufficient time to look at software vulnerabilities that programmers were not able to address. Another important fact is that approximately two million hosts are added to the Internet each month. Many of them do not have system administrators, auditors, and other support staffing, ensuring system security. For the most part, many administrators have become victims of the directive of "keep the system up, regardless of what it takes."

Because many businesses are understaffed and currently shorthanded, they get around to crafting and enforcing policies, risk management, and audits when they have the time. The responsible persons were too busy doing other things to pay attention to default configuration vulnerabilities.

Auditing Common Systems Vulnerabilities

Buffer Overflows

During 1996, a series of articles about buffer overflows and the havoc they can create was published, changing application security forever. One such article authored by Aleph One, "Smashing the Stack for Fun and Profit," detailed the profound effects of buffer overflows on poor programming practices. [3]

In essence, buffer overflows occur when an attacker or other malicious user stuffs more data into a buffer than is allocated. For the technically inclined, this type of overflow input is generally associated with C programming language functions similar to strcpy (), strcat (), and sprintf (). These are merely examples as there are many other types of exploitable functions. Buffer overflows cause a segmentation violation to occur. This type of input can be exploited to gain access to the target system. Buffer overflows are not limited to remote attacks, they can also occur from within the local network.

In this example, the UNIX-based application, Sendmail, will be used. Suppose there is a fixed-length buffer of 255 bytes. This buffer defines the amount of data that can be stored as input to the VRFY command. In this example, the Sendmail application will be running at Root. What is the result if an attacker connects to the Sendmail application and sends a block of data consisting of 10,000 "V" s to the VRFY command rather than the expected user name? The system will crash, essentially causing a denial-of-service attack, as the VRFY buffer is overrun because it is only designed to expect an input of not more than 255 bytes of user input. If the attacker inputs a specific code that overflows the buffer and executes the command /bin/sh, the attacker could reach root access.

When the attack is executed by the system, a special assembly code known as egg is sent to the VRFY command as part of the string used to overflow the buffer. On being overrun, the attacker can set the return address of the offending function allowing the alteration of the program flow. Instead of the function returning to its proper memory location, the attacker executes the code that was sent included as part of the buffer overflow data that will run with root privileges.

It is important to note that buffer overflow codes are specific to systems' architecture and operating systems. For example, a buffer overflow targeting a BSD UNIX, based on an Intel processor will not be effective on a Solaris operating system running on a SPARC processor. From this brief explanation, auditors can see that buffer overflows are extremely dangerous and are the bane of most system administrators. For the most part, attackers must be fairly talented to create a workable egg; however, most system-dependent eggs have been discovered and programmed, and are available from attacker Web sites on the Internet. [4]

Many common system vulnerability lists have a description of the exploit, the systems on which it is effective, and the CVE (Common Vulnerability and Exposure) number. [5]

In the Domain Name Server, DNS, known as BIND, Berkley Internet Domain, there are security vulnerabilities in older versions prior to 8.2.2 with patch 5. Good reason for auditors to look at the application update and change policy of the organization, right? Older and unpatched BIND versions can be corrupted by attackers that allow them to redirect Internet traffic to sites not of the owner's choosing. Poorly configured BIND can allow attackers to download all the names, operating systems, and IP addresses of the organization's internal network. With this knowledge, attackers can search for specific tools targeting machines in your network to gain unauthorized access to your systems.

CGI Scripting

Common Gateway Interface (CGI) is the means by which Web page developers collect and display your input to a Web-based form. CGI scripts are frequently written in PERL (Practical Extraction and Report Language) and uploaded to the CGI-BIN directory located on the Web server. In some cases, developers and vendors have distributed these scripts with vulnerabilities already in them.

CGI scripts can be written in almost any standard input programming language, but PERL is the most common. It is important to note that for each executed CGI script there is a new process started that will be terminated when the CGI has finished. Usually data is sent to the server to be executed or manipulated, and is returned to the user in the form of HTML or images.

By way of review, CGI processing generally follows this way: The user accesses a Web page that requests user-input. After making the input, the user clicks the Send button and sends the data to the Web server for processing. The server forwards the data to the CGI application, sometimes called the CGI script, as these are small programs, where the user-input is processed. After processing the data, it is returned to the server and the server returns the data to the user. It can be seen the potential for vulnerabilities exist with the user-input data. CGI is used to perform functions that normal Web pages cannot. For example, CGIs manage databases of user accounts, calculations, form-input data processing, etc. There are easily available CGI scripts available as part of Web servers, downloaded from CGI Web sites, or developers may write their own.

Before placing a Web server into a production environment, developers should make certain the CGI code has been thoroughly reviewed by quality control managers and auditors for programming errors. It is imperative that CGI scripts are tested thoroughly and retested before being allowed into a production environment. It is equally important that CGI scripts have delimited input in that only expected input and input length are permitted, denying all other types of input.

Attackers have discovered they can corrupt these scripts and cause them to do things they were not intended to do. For example, it is possible for attackers to access collected credit card numbers by corrupting the CGI scripts. It is also possible for attackers to gain root access to the Web server and deface your E-commerce site. If you do not have any production need for CGI scripts, remove them from your system.

In keeping with policy and procedures, auditors should note that all unnecessary services should be disabled or removed thereby reducing the number of vulnerabilities. Also, ensure the Web server software is updated and documented regularly. This will go a long way to minimizing unauthorized intrusions.

Remote Procedure Calls

RPC allows a computer to launch and run a program on another computer. Many client-server architectures depend on this functionality. Those systems that are most frequently affected by RPC vulnerabilities are those based on the UNIX platform, such as Linux, Solaris, AIX, HP-UX, and IRIX. It is important to remember from an auditing perspective that RPC vulnerabilities can be exploited by buffer overflows resulting in the attacker being granted root privileges. The best means to deal with RPC vulnerabilities is to update the operating system's security patches. And, if RPC functionality is not necessary for system functionality, disable or remove it.

Default installations of operating systems and applications frequently use installation scripts to facilitate the installation of the software. In many cases, most of the program's functions are enabled with the least amount of interaction from the installer. Installation scripts usually install more features than the majority of users need. Although this installation action is convenient for users, it deposits potentially dangerous vulnerabilities. They become more serious, as administrators and managers do not actively update software components. For example, it is common for some operating systems and applications to install default passwords for many of their features. If these features or default passwords are not disabled or removed, they provide an easily accessible entry-point for the attacker. In addition, many users do not realize the default features that have been installed. Left unattended, these services provide ready access to attackers both inside and outside the organization. Likewise, it is important that all software is updated on a regular basis, allowing for patches and newer versions to address current vulnerabilities. Change control, management, and documentation is not just a drill. It is a matter of system survivability.

Experience Note 

The fewer open ports and services available on a system, the fewer the opportunities for system vulnerabilities.

Software installers must have standard installation procedures mandating the removal or disabling of unnecessary features and updating software. It is important these installation procedures are written and disseminated to all employees authorized to install software and hardware. Auditors must review the software installation process, making certain all unnecessary features, passwords, and services are removed or disabled, and that all software is regularly updated and those updates are appropriately documented.

Weak, default, or missing passwords is another common systems failing. Most of today's systems are configured to use passwords as the first, and many times, the only line of access restriction. User identification is relatively easy to acquire, and regrettably many business have unauthorized dial-up access that bypass firewall protections.

A more glaring problem is the account that does not have any password protection. As a matter of business sense, all weak passwords, accounts without passwords, and default passwords must be removed from the system or disabled. System attackers usually look for applications and accounts with easy password access. They have downloaded utilities that attack password accounts and are successful more often than not when poor password policies and procedures exist. Auditors should carefully review the company's password and software installation policies and procedures. Testing passwords is easily accomplished by using commercial software solutions available from vendors such as www.accessdata.com.

It is not a matter of if a critical incident will happen; it is only a matter of when. Count on it, it will happen, and it will happen at the worst possible moment. It is Murphy's Law! Recovery from critical incidents requires accurate, reliable, easily accessible backups and tested methods of restoring data. It is a common mistake for organizations to make frequent backups of their data, but never take the time to verify that the backed-up data is viable or that their recovery and business restoration procedures will actually work under the worst possible conditions.

One of the secondary faults of backed-up data is that of physical security and accessibility. More than one security administrator has lost sleep after discovering an attacker has entered the company's system and destroyed sensitive information. Because the backed-up data was stored on a server within the system, the attacker destroyed those files also.

Auditors must ascertain if a system is vulnerable in the face of critical incidents using the simple work paper shown in Exhibit 8.

Exhibit 8: Backup and Data Recovery Audit Program

start example

Backup and Data Recovery

Objectives of this audit segment are to ascertain adequacy of policies, practices, and standards in management and application controls relevant to the backup and recovery activities of the XYZ Corporation's Information Technology Unit, for the period xx/xx/xx to xx/xx/xx. Overarching principles in these audit objectives are confidentiality, integrity, and availability of critical information resources.

  1. Obtain and review organization chart and related job descriptions and responsibilities for Information Technology Unit

  2. Verify critical functions and if these job functions follow principles of least privilege and separation of duties

  3. Obtain and review documents containing relevant policies, procedures, and standards

  4. Test appropriate documents to determine if the backup and recovery policies, procedures, and standards are in compliance with current legal and regulatory requirements

  5. Observe and document where critical backup files are stored

  6. Determine and document if the backup media has sufficient shelf life to store data

  7. Determine and document security measures for backup media

  8. Verify and document if backup media are stored in low-fire-hazard containers

  9. Verify and document the availability of backup media to XYZ Corporation

  10. Test and document accuracy of backup media by performing exercise requiring backed-up data

  11. Verify and document test time requirements in obtaining and restoring data in backup media

  12. Test document procedures requiring information to be backed up

  13. Determine and document if procedures for identifying critical data and their retention periods are appropriate

  14. Verify and document qualifications of employee responsible for administration of backed-up data

  15. Determine and document if there are single points of failure in the XYZ Corporation's information backup and restoration system

  16. Obtain and test samples for accuracy of original information with the backed-up information

  17. Observe and document employee activities relative to information backup and restoration

  18. Identify and document senior manager responsible for employee compliance with backup and recovery procedures

  19. Identify and document ownership of backup media

  20. Identify and observe methods by which backup and restoration takes place

end example

The more open ports you have listening with services on your system, the greater number of attackers that will try to connect and break into your system. If a system feature or service is not absolutely essential, disable or remove it. The IT world would be much safer if this policy were practiced.

Auditors can scan 65,535 TCP and UDP system ports by using a port scanner utility. The most popular and configurable scanner is Nmap [6] There are other port scanners that work as well, but it is probably the most powerful port-scanning tool currently available. Instructions on downloading, installing, configuration, and help files are available at the Web sites. Running Nmap does essentially three things:

  1. It will ping a number of hosts to determine if they are alive.

  2. It will portscan hosts to determine which services are listening.

  3. It will attempt to identify the host's operating system.

Running a scanning utility will show the auditor the specific system ports and services that are open on the target system. Once done, the auditor compares the list with the allowed services in the organization's policies and procedures. Any discrepancies should be immediately investigated and reported.

On UNIX systems, most services are controlled by inetd and the corresponding system configuration file, inetd.conf. Inetd.conf lists the services listening on any given port, and this configuration tool can be used to close unneeded ports. If a service in the inetd.conf has been removed, restarting the system stops the port from being opened. There are other services started in /etc/rc or /etc/rc.local. Consult your system's documentation about disabling these scripts as UNIX features vary between versions. In the case of Windows NT products, consult with the Window NT system's documentation about disabling or removing services on open ports.

Incomplete or missing logging is a frequent system fault. When systems are attacked, your saving grace is the existence and completeness of logs. Without logs, you will have no idea what happened in your compromised system and, worse yet, no one will know when the system became corrupted, so no one will know how far in the past data and applications will need to be restored. It is possible that the attacker still has access to the system. Logging must be done on all critical systems. It is highly recommended that logs are written to Write Once Read Many, WORM, media such as CD-Rs. Logs should be sent to remote systems making their compromise that much harder. Logs should be saved and backed up in the same fashion as other valuable data. Auditors should review logs in determining if unacceptable behavior has taken place. For example, if an employee has the responsibility for accounts payable, why would this employee be logged as viewing a sensitive project under development? Another auditing test may consist of comparing logs stored as backups and logs present on the system. If there are discrepancies, an attacker may have altered the logs after they were backed up to conceal her activities.

Improper or nonexistent filtering of incoming and outgoing address packets is a common mistake made by firewall administrators. There is a popular denial-of-service attack where the attacker sends literally millions of packets containing spoofed IP addresses of the target system to the target system. Receiving the spoofed packets, the target system crashes. However, if routers and other network devices are configured to filter incoming (ingress) and outgoing (egress) traffic, a high level of protection is afforded. Here is an example of some egress and ingress filtering rules:

  • All ingress packets must not have a source address of any of the organization's internal network.

  • All ingress packets must have the destination address of the organization's internal network.

  • All egress packets must have a source address of the organization's internal network.

  • All egress and ingress packets must not have a source or destination address of an address of the internal network and must not have an address in RFC 1918; [7] these include addresses: 10.x.x.x/8, 172.16.x.x/12, or 192.168.x.x/16, and the loopback network address, 127.0.0.0/8.

  • All IP addresses with the IP options field set should be blocked.

  • All reserved, dynamically assigned addresses (DHCP, Dynamic Host Control Protocol) and multicast addresses must be blocked including:

    • 0.0.0.0/8

    • 169.254.0.0/16

    • 192.0.2.0/24

    • 224.0.0.0/4

    • 240.0.0.0/4

In Windows systems, there is a protocol known as the Server Message Block that enables file sharing over networks. Although many employees have the best of intentions, they knowingly or ignorantly change the configuration of Windows, allowing coworkers to access and write to their files. By doing so, they also make these files available to attackers. Additionally, the default installation of some operating systems allows file and printer sharing.

Experience Note 

Exploiting file and printer shares is probably the most common attack.

This is a simple checklist to address unprotected sharing:

  • Ensure that workstation file and printer sharing are disabled. Remember that they will likely be enabled from a default installation.

  • If file sharing is determined to be absolutely essential, ensure that specific files are accessed with strong passwords.

  • In the case of Windows NT platforms, use file permissions to ensure that only enumerated users have access privileges.

  • Block ingress connections, at the firewall, to the NetBios session service on port 139 and port 445.

This list of common system vulnerabilities is not intended to be a comprehensive list, but it should provide some degree of guidance. There are security lists available on the Internet and should be considered dynamic documents, as they frequently change as systems and vulnerabilities change. Many system vulnerabilities are application or operating system specific and many are not. Auditors must keep abreast of current vulnerabilities as they apply to critical assets, ensuring they are incorporated in the organization's risk management program, policies, and procedures, and audit programs.

Experience Note 

Auditors are generally the last line of proactive defense against onslaught of risks. If they do not discover the problem, it will likely go undiscovered until the critical incident brings the organization to its knees.

Exhibit 9 is a brief example of an audit program for a small organization's IT unit.

Exhibit 9: Audit Report for XYZ Corporation Backup and Recovery Unit

start example

Table of Contents

This table of contents should include major sections, with references to the tabbed work papers located in a separate binder.

Executive Summary

Restate conclusions for each audit objective listed in the audit program summarizing significant findings and recommendations.

Background

Provide background information about the purpose/mission of the audited area. Include reason for audit such as suspected irregularities or routine audit interval. Indicate in this section whether this is a follow-up on a previous audit.

Audit Objectives

List audit objectives in an organized fashion.

Scope and Methodology

Identify audited activities, time period audited, and nature and extent of audit tests performed. This is the section to explain any sampling methodologies used in controls testing.

Audit Results

This section should be restricted to documented factual and supported statements. Statements of opinion, assumption, and conclusion, such as "disclosure of health care information is a violation of employee privacy," are more effective than "internal data controls were weak."

Auditors can make recommendations that are preceded by a narrative of the finding, followed by the corresponding manager's response to the recommendation. In other words, the results of the audit report are presented to the managers for their input before the final report is drafted. If the manager's response is excessively long, then a summary of the response should be included in the report and the complete response tabbed and placed as part of the appendices.

Conclusion

The auditor's opinion or conclusion based on the objectives of the audit should be stated.

Prior Audit Results

Prior Recommendations

Prior Management Responses

Current Year Follow-Up

    

________________________________________

Senior Audit Manager

________________________________________

Senior Operations Manager

Appendices with Corresponding Tabs

  1. The Nature, Timing, and Extent of Audit Tests

  2. Follow-Up on Last Audit's Recommendations

    The following table summarizes the last audit results, recommendations, management responses, and the results of our current audit results.

  3. Standards for the Professional Practice of Internal Auditing

    Standards for the Professional Practice of Internal Auditing require that we plan and perform audits with the objective of obtaining reasonable assurance about whether internal controls are effective; whether internal controls provide reasonable assurance that XYZ Corporation is complying with applicable laws and regulations; and whether internal controls provide reasonable assurance that management understands the extent to which XYZ Corporation's operational objectives are being achieved effectively and efficiently. This audit includes examinations on a test basis, control environment, risk assessment, management control activities, application controls, and monitoring and development activities. We believe our audit provides a reasonable basis for this report.

end example

Audit Work Papers

Audit working papers are essential tools of auditors. They support the auditor's opinion. They should be inclusive, comprehensive, and serve to:

  • Support the record that the audit was performed in conformity with auditing fieldwork standards

  • Aid the auditor in conducting, assigning, and coordinating the audit

  • Provide evidence of supervision and review

  • Assist in planning and executing the next audit

  • Provide a means by which audit steps may be reconstructed at a later date

  • Provide evidence of professional due diligence

Experience Note 

The last item has been one of the most important work paper purposes. It is strongly recommended that each work document contains a heading detailing the business unit, purpose of the work paper, and the date; a place for the preparer to initial and date, thereby adopting the content of the work paper; a place for the audit reviewer or manager to initial and date, thereby adopting the content of the work paper and all audit work papers must be collected into binders, organized by content, indexed, and archived.

It is important to note that audit management plans, program, interview notes, sampling methodology, related notes, and the final report are considered work papers.

Audit Report

Audit reports are the expected results of an audit. This is the document everyone wants to see. It contains the "guts" of the audit by describing the audit's objectives, methodology, predication, findings, and recommendations and surprisingly, may offer words of praise. In the final report, auditors should meet expectations but not drown their intended audiences with excessive narratives, jargon, and techno-speak. Reports should get to the point early and not dawdle excessively in narratives. If the audit report is lengthy, and most are, include an executive summary section. If during the audit, criminal or potentially damaging activities are discovered, they should be brought to the attention of senior managers immediately on their discovery. Wise auditors will document their conversations and make them a part of the final audit report. It is the responsibility of the person discovering criminal activity to report it to authorities.

Experience Note 

If anyone has questions concerning their obligation to report federal criminal matters, he would be wise to review 18 U.S. Code 4. If anyone does not have access to the latest paper-based version of the federal criminal statutes, they can be located at: www.findlaw.com. It is not considered a bar to individual prosecution to say you reported criminal acts to your senior managers.

Exhibit 9 is an outline of an audit report.

[2]Available at www.iso.ch.

[3]This article is available at www.2600.net/phrack/p49-14.html.

[4]Another reference paper detailing the effects of buffer overflow attacks written by "Dildog," titled "The Tao of Windows," can be found at www.cultdeadcow.com.

[5]CVE numbers can be referenced for explanation at www.cve.mitre.org.

[6]Nmap is available for UNIX at www.insecure.org/nmap, and for Windows NT at www.eeye.com/html/Research/Tools/nmapnt.html.

[7]Referred For Comment document number 1918 may be located at www.ieee.org.



 < Day Day Up > 



Critical Incident Management
Critical Incident Management
ISBN: 084930010X
EAN: 2147483647
Year: 2004
Pages: 144

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net