Audit Conferences: More (but Important) Meetings You Need to Attend

Opening Conferences
Opening conferences occur at the initiation of the audit and should communicate the scope of the audit, the audit's objectives, introduce the audit staff, agendas, schedules, and relevant handouts. In part it is an opportunity to explain in professional terms the purpose and expected results of the audit to the employees who are going to be going to be participating in the audit. The entrance conference should be conducted with the following in attendance: Directors, or department heads responsible for the area being audited, managers and their subordinates who work in the specific audit target and any appropriate senior employees.

A typical entrance conference will have an agenda similar to the following:

Welcome

Introduce auditors and related audit participants

Review audit objectives

Review audit steps

Review time schedule

Identify relevant points of contact for each step

Describe the audit process from the auditor's and target's perspective

Set up first contact appointments

Conclusion

Other Conferences
During the course of the audit, there will likely be reasons for other conferences. For example, if an auditor finds there is something of a fraudulent nature, this should be brought to the attention of senior managers immediately. This meeting will take place behind closed doors. It is recommended that conferences between the entrance and exit conference take place away from the eyes of employees. If held before employees' view, they tend to foster unwarranted speculation, and damaging rumors can be fomented. Conferences of this type should be scheduled away from the work area being audited. In the case of reporting potential criminal activities, it is strongly recommended that the persons participating in this conference communicate through out-of-band means. Cellular telephones and communications methods, not using the organization's communication networks, are the best out-of-band communications. Involve the appropriate levels of staff including senior managers, legal unit, security unit, and risk managers in all conferences.

One point of professional due diligence is the discussion of the audit findings somewhere toward the end of the audit with the senior managers of the unit being audited. This gives them a chance to see any "hot grounders" headed their way. Responding to the auditor's findings is an effective way of determining if the auditors "hit their marks" with their work. Most senior managers realize their strengths and weaknesses before the audit takes place. Often the audit results merely provide them with the motivation to take corrective action.

An end of audit conference provides a formal means for a meeting of the minds and makes a matter of record of the audit's performance in the eyes of the responding managers. If there are serious differences between the auditor's findings and the manager's responses, it may be the auditors did not have a sufficient grasp of their material or they were not diligent in their efforts. In a worst-case scenario, it could mean the senior managers were out of touch with their business processes. In the former case, it is the responsibility of the audit managers to see that audit team members receive training to bring their skills up to par or find ways to motivate them to diligently perform their tasks.

Meetings whose purpose it is to preliminarily discuss their findings, allow senior managers an informal opportunity to discuss the audit findings and recommendations. This is a useful technique in addressing significant findings and permits the meeting's participants to determine if a follow-up audit is going to be needed.

Usually, follow-up audits are very narrow in their scope focusing entirely on those significant findings of the previous audit. Follow-up audits are much abbreviated, do not have opening or closing conferences and are staffed only with enough auditors to review the findings for compliance.

Exit Conferences
The auditors have completed their work, the report is done, and it is time to bring the audit to a close. Often, auditors deliver a performance survey to the managers of the target business unit. Such surveys have the purpose of collecting information about the performance of the auditors and the audit in general. Audit managers commonly use these surveys in completing the auditors' performance appraisals.

The agenda below is typical of a closing conference:

Welcome

Review audit objectives

Review audit steps

Briefly review controls adequacy

Briefly review controls recommendations

Present draft report

Field any questions from the attendees

Conclusion

Summary of Audit Steps
By way of summary, here are some steps to successfully completing audits:

Preparation

Predication for audit, routinely scheduled or based on an allegation

Form audit team from qualified employees

Prepare audit management plan

Prepare and deliver preliminary questionnaires

Prepare audit program

Prepare audit budget

Field work

Entrance conference

Audit field work

Audit status conference

Prepare draft of report including senior management responses

Exit conference

Conclusion

Prepare final audit report

Complete audit performance survey

Schedule follow-up audit, if necessary

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.

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.

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.

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.

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.

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.

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.