i-data-recovery.com

IT Audit Course: How to make a report of IS Auditing

Saturday, July 31st, 2010

BASIC AUDIT REPORT

The contents of most audit reports follow a similar pattern and include:

• Background, scope, and objectives
• Summary of major findings
• Audit opinion
• Detailed findings and recommendations
• Acknowledgments of satisfactory performance
• Detailed technical appendices

A cover is almost always desirable because it sets a professional tone from the start. It should include the report title, name and location of auditee, and the date of audit coverage.

A formalities section normally constitutes an introduction and is typically one to three pages in length. It includes the date of the report, the addressee (get it right), and the background, scope, and objectives of the audit. A brief audit opinion and the general nature of the findings together with the reply expectations and a signature are required. The names of participating auditors, distribution list, and contents of the body of the report are also a normal part of the formalities section.

EXECUTIVE SUMMARY

Most audit reports include an executive summary covering the most important issues and findings from an overall business point of view. The executive summary provides a preliminary perspective to the whole report and focuses on risks to the organization and the specific effect of control weaknesses. It may be all that is read and, in many cases where such summaries go to senior executives, it is all that should be read.

Two approaches are possible in the executive summary, depending on the nature of the executive audience. With a knowledgeable executive, a condense and eliminate approach may be used. This involves an abbreviated explanation of major audit findings, in order of importance to the executive and cross-referenced to the body of the report. A briefings approach that informs, advises, and interprets may be more appropriate in a specialized audit where the executives may not be fully conversant with the implications of findings.

DETAILED FINDINGS

Detailed findings usually constitute the body of the report. Strange as it sounds, a finding is not something that was found. An audit finding is comprised of four distinct parts:

1. Condition. Records what was found by the auditor (i.e., what the evidence showed)
2. Criteria. Indicates what should have happened in terms of control considerations
3. Cause. Indicates whether the condition was caused by the absence of an internal control or the failure of one and, if so, which
4. Effect. Indicates the impact on the business of the cause of the condition

Many auditors struggle to decide how much detail should be included in the body of the report. The detailed findings should include sufficient information for the reader to understand the nature of the finding, the relative importance of the finding, and what needs to be done about the finding. There can be no clear-cut rule on this because it depends on the knowledge level and experience of the audience being communicated with. During the course of the audit, the auditor should assess how much detail will be required in the final report. In order to ensure the final report is readable, exhibits and attachments are usually placed in an appendix if placing the information in the body of the report would make it overly lengthy or unreadable. All graphics, charts, photographs, and financial tabulations should be clearly labeled within the report in case they are referenced in two or three places. Where appendices are used they should be cross-referenced to the report.

One of management’s common requirements is the expression of an audit opinion. This normally takes the form of an opinion on the adequacy and effectiveness of the internal control structures. The auditor must bear in mind that an opinion on adequacy is an indication that the control structures do or do not achieve management’s desired level of control. Many auditors express an opinion on whether the control structures meet their own definition of adequacy. The audit opinion provides an overall perspective to the rest of the report and forces auditors to commit themselves, but can cause a management overreaction resulting in important parts of the report being ignored because, by their nature, audit results are normally mixed.

Auditee responses to findings and recommendations are normally included in the final report. This assists provision of a balanced report and can lend credibility to the report. Where such comments are included, they must be reviewed with and agreed by the auditee. This does not mean, however, that the auditee must agree with all of the auditor’s findings and recommendations. In some cases the two parties must agree to disagree with both opinions expressed within the report so that the managerial decision can be made. If the manager decides to accept the risk expressed within the report and take no action, and if such a decision is within their area of authority, the auditor has done their work in drawing the risk to management’s attention and no further audit effort is required in this area.

POLISHING THE REPORT

Because the audit report is a reflection on the professionalism and competence of the whole IS Audit function, the report must appear as professional as possible. Polishing the report involves a rigorous review prior to issue. This can be done by using a checklist to ensure the readability and understandability of the report or by using a peer group, which normally involves one auditor with no knowledge of the specific audit area so that assumptions may be challenged. Ultimately the report will be signed off by the in-charge auditor or a designated deputy. One of the major auditee complaints is that reports containing critical issues are issued late and that they are expected then to implement the recommendations with immediate effect. It is therefore critical that the auditor does not build in delays to report issuance.

Commonly the audit report will involve the coordination of several writers’ efforts. In such cases is may be wise to read the report aloud and recognize the differences where individual contributors change.

DISTRIBUTING THE REPORT

Audit reports are normally distributed to a variety of managerial levels. The report should be directed at the first authority level able to take appropriate action. The full distribution list is normally known early in the audit process; however, auditee chains-of-command can cause internal political ramifications. Many IS Audit reports are sent to the recipients by e-mail. In general, the delivery method should take into account both the confidentiality of the reported information as well as the remoteness of the recipient. Couriering or hand-delivery may be preferred but impractical. If e-mail is used, adequate encryption techniques should be implemented to ensure the confidentiality and integrity of the message delivered.

If the audit report contents are highly confidential, detective controls can be implemented to trace individual copies should a leak occur. The most obvious of these techniques is copy numbering, but intentional misspellings or rewording of critical areas may also be used.

Tags: Data Forensic, Information System Audit

Posted in Information System Audit | No Comments »

IT audit course: Processing of IS Audit Evidence

Saturday, July 31st, 2010

IS AUDIT EVIDENCE PROCEDURES

As has been stated, the auditor gathers evidence by following the audit program, which is a set of detailed steps that the auditor will follow in order to gain the appropriate evidence and, for the Information Systems (IS) Auditor, may well include the use of computerized techniques, although this is not always the case.

The evidence gathered permits the expression of an opinion on the efficiency, economy, and effectiveness of the activities. It lists directions for the examination and evaluation of information and provides the primary link between the audit field work and the audit report.

Steps in formulating the audit program involve determining the results from the preliminary survey, determining what, if any, risk is indicated; determining what types of controls best manage the risks; determining what, if any, additional evidence the auditor would like; and selecting the audit tests.

Like a route map, the audit program must fit the need of the traveller. It states what is to be done, when it is to be done, how it is to be done, who will do it, and how long it will take. The audit program helps the auditor stay on schedule/budget. It may be “pro-forma” or specifically tailored, but in either case it provides the following benefits:

• It is a systematic plan for each phase of audit work providing a basis for assigning work to the team members.
• It is a means of controlling and evaluating progress and assisting in training inexperienced staff members.
• It provides a summary record of work done.
• It reduces the direct supervision requirement by providing a clear path for subordinates and provides internal audit quality assurance information.

The final audit program should be prepared immediately after the preliminary survey although even then the program may be modified during the audit. Where new pro-forma audit programs are to be introduced, they should be prepared well in advance and field tested. Programs that are prepared too late will be rushed and have steps missing.

Preparation of the audit program should focus on what is hazardous to the corporation. The program should be thoughtful, relevant, effective, and economic, remembering again that not every item need be checked and that reasonableness and relevance should be maintained.

CRITERIA FOR SUCCESS

In order for the audit program to be successful, the objectives of the operation should be stated and agreed by the auditee up-front. The programs should be tailor-made where possible and the reasoning behind each work step should be shown. A common failing of audit programs is the creation of a list of questions to be answered. The audit program is a series of detailed instructions to be followed in the obtaining of audit evidence. These work steps should be prioritized to seek evidence of the most important control objectives first. All audit programs should be flexible because circumstances may change based upon evidence uncovered. Supervisory approval must be shown for all audit scheduling, staffing, and the audit constraints must be agreed.

Audit supervision will typically utilize standard project management techniques in order to match resources to requirements. This will include the defining, organizing, and monitoring of tasks and training staff as well as approval of the audit program.

The audit supervisor must be satisfied with the:

• Audit subject
• Audit objective
• Audit scope
• Pre-audit planning
• Selection of audit procedures
• Procedures for evaluation or testing
• Procedures for communication
• Report preparation

• Follow-up review
• The audit program provides for the collection of audit evidence of:

Structures

Documentation standards

Systems documentation

This may involve interviewing personnel, observing performance, or statistical sampling.

The overall audit approach must be:

• Simple
• Practical
• Quick
• Commonsense
• Business oriented
• Technically competent

STATISTICAL SAMPLING

In many cases the auditor can gain adequate assurance regarding the mitigation of risk without having to examine every single record or transaction. Under such circumstances, the auditor may choose to use a variety of sampling techniques in order to obtain evidence that is satisfactory and competent. The auditor may choose to use either non-statistical or statistical sampling techniques.

Non-statistical sampling involves the auditor making a judgment call as to the number of items to be selected and which items. The sampling technique is valid where the auditor wishes to examine a few examples without necessarily drawing conclusions about the whole population.

Statistical sampling itself is the process of testing a portion of a group of items to evaluate and draw conclusions about the population as a whole.

Statistical sampling may be defined as follows:

The auditor is performing either a compliance test, or a substantive test of either documented internal accounting controls or accounting source records by applying procedures to less than 100% of the items in the class of transactions or account balance for the purpose of forming a conclusion about some characteristic of the class or balance.

WHY SAMPLE?

The underlying assumption of sampling is that the results of a sample yield accurate information about the population from which the sample was taken. Sampling, therefore, can be viewed as an effective method of gathering audit evidence.

If auditors did not use sampling, every item comprising an account balance or every transaction occurring within a class of transaction would need to be reviewed. The cost of such an examination would (a) be prohibitive due to the amount of time required to perform such an examination and (b) far outweigh the benefit obtained. Sampling provides the auditor with a means of obtaining almost identical information, but at a much lower cost. Thus, sampling is also an efficient method of gathering information.

There are two basic sampling approaches:

1. Judgmental/nonmathematical
2. Statistical

Each approach represents a different way of handling audit risk. Therefore, each may be appropriate for some populations but not for others. Choosing the appropriate approach involves answering some critical questions about risk, population characteristics, and the objectives of our testing. The answers lead us to the best approach and the most efficient audit plan.

JUDGMENTAL (OR NON-STATISTICAL) SAMPLING

In judgmental sampling, the auditor relies solely on his/her professional judgment to assess the risk of sampling error and evaluate the population. Because the sample is not intended to be representative of the whole population, sample results cannot be extrapolated to the whole population. This approach is normally used where the auditor intends to use the sample for limited purposes.

Where the auditor is aware that a section of the population is higher risk, the auditor may choose to direct the sample to that particular area. Once again, the auditor has exercised professional judgment in selecting the population to be reviewed and conclusions drawn must be carefully judged to ensure their validity.

Judgmental sampling should not be used as a primary audit procedure if the auditors have no special knowledge about which items in the population are more likely to contain misstatements.

Again, judgmental sampling may be used for limited purposes (i.e., when sampling is not the primary audit procedure) such as corroboration of the outcome of other analyses by examining a few detailed transactions to check the validity of forecasts.

QUANTITATIVE METHODS

In addition to statistical analysis, a variety of quantitative methods are also available to be selected by the internal auditor. These mathematical tools are commonly used to obtain an understanding of operations and permit the drawing of conclusions in a variety of circumstances through analyzing the complexities of situations. Of the many quantitative methods available to the auditor, the following sections examine the most commonly used.

Trend Analysis

Trend analysis is used to evaluate the behavior of a variable such as turnover of a period of time. Such analyses can serve as evaluation criteria to determine the reasonableness of fluctuations of an extended period. Comparisons of this year’s turnover to last year’s turnover or, alternatively, this month’s turnover to the same month last year are popular.

Chi-Square Tests

Chi-square analyses are non-parametric tests capable of analyzing relationships between qualitative data. For example, do operating units in the South have particular patterns of operation different from those in the North?

Chi-square tests can check for the independence of normal classifications and ordinal data, and require no particular distributional pattern for the data.

Correlation Analysis

The measurement of the extent of association of one variable with another is known as correlation analysis. Two variables are said to be correlated when they move together in a detectable pattern. A direct correlation is said to exist when both variables increase or decrease in the same time although not necessarily by the same amount. For example, one would expect inventory to decrease as sales increased.

Correlation analysis is used by internal auditors to identify those factors that appeared to be related. An operational auditor, for example, may use correlation analysis to determine whether corporate performance is in line with industry standards by comparing the correlation of company costs of imported parts with the exchange rate fluctuations. Problems with how these statistics are computed; shortcomings in the internal auditor’s understanding of auditees’ operations, or real inefficiencies or misstatements can be pinpointed through correlation analysis.

Graphical Analysis

Graphical analysis can be useful to the internal auditor in identifying interrelationships in data, anomalies, and simple data errors.

A common form of graphical representation use by the auditor is a scatter diagram, which refers to any graph of data points. The more discernible a pattern appears in the graph, the more likely one variable is related to another and therefore can be used to predict the other’s value. Where no pattern can be noted, there would appear to be little, if any, correlation between the two variables.

Where a strong correlation exists, either positive or negative, the correlation value will approach 1. Where little correlation exists the correlation value will approach 0. Unfortunately, correlation values only measure linear patterns. Where there is a nonlinear relationship, correlation statistics will not disclose this. Occasionally the correlation value can be distorted by a single data point not conforming to the general pattern. While this can be readily seen on the graph, it may be less obvious in examining the correlation value.

Learning Curves

In conducting operational audits of performance levels of the implementation of new procedures for the quality of training of new staff, a learning curve would normally be expected to be observed. As employees gain experience with the new procedures or as the new employee becomes more experienced, the length of time taken to task should decrease.

Learning curves are evaluated by computing the time required per unit of production each time that the cumulative output is doubled. A decrease in production time per unit of 25% would result in a 75% curve. The 60% curve would result if the production time was reduced by 40%.

By measuring this curve the auditor can determine how quickly a new procedure or employee becomes productive. When a new procedure is recommended, calculating the initial time per unit under the old system and comparing it to a series of observations over time using the new procedures can objectively determine the impact of the revision to the procedures.

Ratio and Regression Analysis

Ratio analysis assumes a given proportional relationship between two numbers and is normally used for comparisons over time. A more advanced form of ratio analysis attempts to quantify the interrelationship in order to facilitate predictions in a regression analysis. Regression analysis is used to estimate the effect that a movement in one variable (the independent variable) causes a movement in the other variable (dependent variable); for example, if the sun shines, more cool drinks will be sold: but how many more? By performing the regression analysis the relationship, if any, can be identified and quantified and sales levels predicted.

Regression analysis can thus assist the auditor in understanding and quantifying data interrelationships. Unusual variations between expectations and recorded values may be noted for further investigation.

Using software, the auditor can additionally conduct a multiple discriminant regression analysis relating the independent variable to a number of dependent variables simultaneously. By determining the comparative strength of the relationships, the auditor can choose the focus area to achieve greatest impact in performance improvement. Such analysis has also been used to attempt to predict bankruptcy.

As with most statistical tools, regression analysis is based on a set of underlying assumptions that must be met for its use and interpretations to be valid.

Linear Programming

Linear programming is an operations research tool used for the allocation of scarce resources or to determine optimal blends of raw materials. The constraints applicable are reduced to algebraic formulae, which are then solved by simultaneous equations. For example, in a production environment, machining may be capable of processing 100 units per machine, while finishing can handle 35 units per machine. The question of how many of each machine should be used for optimum production can be solved using linear programming.

PROJECT SCHEDULING TECHNIQUES

Accurate project scheduling techniques have long been a goal in project management. Internal auditing frequently works in project teams that often suffer from the same poor project scheduling.

Program Evaluation Review Techniques

The program evaluation review technique (PERT) is used to diagrammatically identify dependent and independent activities. By showing graphically which activities cannot be started until the previous activities have been completed and, at the same time, which activities can proceed simultaneously, the planner can allocate resources to those tasks having the most impact on the final completion deadline. This technique also takes into consideration operational constraints placed on the resources needed to carry out the tasks.

In Exhibit 9.2, the shortest time to get from A to E while completing all tasks is calculated by calculating the longest path. Other times and paths include:

• Path A-B-C-D-E takes 8 days
• Path A-F-G-D-E takes 5 days
• Path A-H-I-E takes 9 days

EXHIBIT 9.2 PERT Chart

This means that the bottom path would be the most critical. The reason for this is that any delay in this path will postpone the final completion date. Any delay in the middle path that does not exceed four days will have no effect on the final completion date. Should the top path experience a delay in any of the processes of, for example, three days, then the top path will now take 11 days to complete and will become the critical path. If, by the same token, the time taken for the critical path can be reduced, then final completion date can be brought forward.

Critical Path Method

The critical path method (CPM) is a scheduling tool that was developed independently of PERT but uses a similar diagram. CPM, however, uses two time estimates: one for normal effort and one for “crash” effort. “Crash” time is the time required for completion if all available resources were committed to that task.

GANTT or Bar Charts

One of the simplest planning tools requiring no mathematical calculations is the Gantt chart. It is commonly used in organizing work and monitoring progress through the various stages of a simple project and involves the production of bar charts showing the start and completion times of individual project activities. The major drawback to these charts is the poorer representation of interdependencies.

SIMULATIONS

Monte Carlo Simulations

Computers can be used to accelerate timescales by carrying out activities repeatedly very rapidly. By combining this with the probability of events occurring, a sophisticated model can be built.

One such approach is referred to as the Monte Carlo Method. It uses the computer to simulate uncertainty via random behavior based on the probabilities entered and then estimates specified models several times to determine average performance.

Game Theory

The term “game theory” refers to mathematical models of optimal strategies under various incentive schemes. This is used in competitive environments to explore “what if” solutions.

A non-zero-sum game is said to exist when a profit is generated in which it is possible for both participants to share. A zero-sum game denotes a situation where a profit simply transfers from a loser to a winner. Game theory is used to assist the internal auditor in understanding the reasons particular strategies are pursued in negotiation sessions or competitive price setting.

Queuing Theory

Businesses often have queues at service points. Elimination of these queues by increasing the number of service points would result in service points frequently being unused and costs increasing. Management frequently must decide how many service points should be provided.

Queuing theory facilitates the use of mathematical models to minimize the total cost for a given rate of arrivals; the minimized cost includes both service costs (facility and operating costs) and waiting costs (the idle resources waiting in line or having service points idle).

COMPUTER ASSISTED AUDIT SOLUTIONS

In today’s environment, a review of business systems will almost inevitably involve the use of appropriate information retrieval and analysis programs and procedures. The auditor will use test transaction techniques to review system-level activity. In advanced auditing, the use of knowledge-based systems will permit the distribution of advanced audit techniques to less skilled staff. Confusingly, these are commonly referred to as Computer Assisted Audit Tools, Computer Assisted Audit Techniques or more correctly, Computer Assisted Audit Tools and Techniques.

Computer Assisted Audit Tools and Techniques are needed because of the large volumes of data in multiple locations involved in the managing of a complex business environment.

The use of computer assisted audit solutions involves the merging of software into an audit program. In order for this to prove effective, key control questions must be predefined in order to facilitate the use of the technology to analyze the data and provide the answers.

Advantages from the auditor’s perspective include increased auditor productivity, creativity, and the application of a consistent methodology.

Information retrieval and analysis programs and procedures include programs that organize, combine, extract, and analyze information. This includes generalized audit software as well as application and industry-related software. Customized audit software and information retrieval software as well as standard utilities and on-line inquiry may also be utilized for information retrieval and analysis. Where the auditor has computer skills in programming, conventional programming languages may provide a viable alternative, but a lack of such skills does not preclude auditors from utilizing such techniques. The ready availability of microcomputer-based software, which provides computing power without the requirement of technical expertise, puts direct data analysis within the toolkit of any auditor. The primary requirement is an understanding of the business application and how data relates.

Tags: Data Forensic, Information System Audit

Posted in Data Forensic, Information System Audit | No Comments »

Penetration Testing 2

Saturday, July 31st, 2010

Chuck Bianco, FTTR, CISA, CISSP

Penetration testing is not a be-all, end-all for security. Organizations must ?rst perform risk assessments that determine the components of sound security policies and procedures. After the development, approval, and installation of security policies, organizations should install several control mechanisms to measure the success or failure of the risk analysis and security systems. One such control is a properly constructed penetration test.

What Is a Penetration Test?

Penetration testing involves examining the security of systems and architectures. It reviews the effectiveness of the security of the organization’s Internet presence. This includes all the holes and information that might damage the organization. The tester uses his creativity and resourcefulness to behave in the same manner as a hacker would.

The tester uses hacking tools and related techniques to challenge the ef?ciency and competence of the security design. The tester hopes to ?nd problems before the hackers do and to recommend ?xes and solutions to identi?ed vulnerabilities. Although penetration testing assesses security from the Internet side or the organization’s network, it is not a full security assessment or a guarantee that your site is secure.

It is only a complement to a full range of security measures. Your company should already have a complete security policy based on a risk analysis of the data and items you need to protect. If you do not have a security policy in place, you may choose to use penetration testing to assist you in writing the security policy.

The penetration test is simply another security tool to assist in protecting your company’s assets. There are several different types of penetration tests, depending on the depth of the test and the threats measured. Both outsiders and employees or trusted third parties can launch attacks on the company. The testing may be broad-based or narrow, depending on risk assessments, the maturity of security policies, prior testing histories, etc.

You may wish to test your systems from internal attacks or develop specialized penetration tests later.

Why Do It?

Many institutions offer Internet banking and related E-commerce activities. Some offer services through service bureaus and others offer the services on institution-run transactional Web sites. All institutions should ensure that they use all systems in a safe and sound manner. Intruders hack both institutions and service bureaus. These hacks place the assets of the institution in peril. The FBI claims that almost 60 percent of all business sites have been the victims of unauthorized access. Some companies have lost money. Many have been the victims of a denial-of-service (DoS) attack, in which a hacker sends more information than your system can handle. This causes your system to slow down or stop working. Examiners and auditors frequently ?nd that the institution does not know whether or not it has suffered a security breach. According to the Computer Emergency Response Team (CERT) and the U.S. Department of Energy Computer Incident Advisory Center (CIAC), hackers invaded more than 25,000 sites in 2001.

Intrusions can lead to loss of money, data, and productivity. Hackers, spies, and competitors can all steal, regardless of whether or not an intrusion occurs. For example, hackers can take advantage of bugs in Web sites to gain unauthorized information. We have even discovered many examples where poorly designed Web sites allowed visitors access to unauthorized information. Therefore, even authorized visitors can copy information and can sell con?dential customer information and strategic information to competitors. These attacks can damage the institution’s reputation and expose it to legal action. The intruder can also install entrances for future activity, such as backdoors, Trojan horses, and program worms. A well-planned test reenacts all such actions. Penetration testing will normally provide evidence of exposures before they occur. In the case of found Trojan horses and viruses, it will act as a detective control.

Penetration testing not only improves security but it helps to train your staff about security breaches. It provides evidence of proper care and diligence in the event of lawsuits ?led because of an intrusion. Moreover, penetration testing authenticates vendors’ claims about their product features. We advise you to have the test performed by a disinterested third party. For example, if the tester recommends that you purchase his product after he completes the test, he may not recommend the most effective solution. He also may not ?nd security weaknesses in his products. The testing must be impartial and provide a view of the entire security system.

All institutions that offer E-commerce products should perform annual penetration tests. In no way does this mean that an annual test is suf?cient to ensure effective security. We believe that the institution should conduct such tests at least once per year and present the testing report of ?ndings to the board of directors. However, the security plan must indicate how much penetration testing is suf?cient. For many sites, an annual penetration test is the equivalent of having the security guard only check if someone locked the front gate after closing time about once a year. Many testers offer yearly contracts for regular testing, which most organizations ?nd extremely helpful in keeping up with the number of exploits and holes published daily.

Institutions using service bureaus should insist on annual penetration testing of the service bureau. Ideally, the institution will take part in the penetration test. The service bureau should issue report ?ndings to its client institutions. The institution should use this report to design a limited penetration test at the institution. An exception to this requirement occurs when the institution takes an active part in the penetration test of the service bureau.

Costs

Costs of such tests can vary from as little as $2000 for targeted tests to several hundred thousand dollars. The risk assessment or Standard of Due Care Study and your security policy determine the extent of the test and necessary costs. Institutions will include penetration testing costs in cost/bene?t studies as part of the business analysis decision.

Limits

The institution should carefully design the scope of the penetration test to protect the company from inad-vertent downtime and loss of business due to a successful intrusion during the test. While it may also be impractical to allow the tester to have access to production systems, testing does not have to be perilous if done at low traf?c times.

While the tester may be limited because the employees know about the penetration test, this knowledge only hampers penetration testing if the tester is also attempting to measure human security controls. Some testers prefer that company personnel know about the test in advance, so that the employees can tighten security before testing. For example, weekly penetration tests will cause the employees to apply patches the moment they come out, rather than waiting for a penetration test report showing they are not doing their jobs. Moreover, professional testers will notify the company as soon as they ?nd any high risks and have it ?x them immediately. They will still include the risks in the report, but the tester does not leave the company at risk during the testing and report-writing time.

The company must take great care to carefully design the limits and scope of the penetration test; yet it must also allow the tester suf?cient access to evaluate security effectiveness. The organization should de?ne exactly what the tester can and cannot test. These requirements should go in the contract and be de?ned by IP addresses.

The test can include, but is not limited to, the following tools and techniques (see http://www.cccure.org/ modules.php?name = Downloads&d_op = viewdownloaddetails&lid = 9&ttitle = Domain_1.zip for more detail):

• Network mapping and port scanning

• Vulnerability scanning

• Wardialing

• Snif?ng

• Spoo?ng

• Session hijacking

• Various denial-of-service (DoS) and distributed DoS (DDoS) attacks

• Stack-based buffer over?ows

• Password cracking

• Backdoors

• Trojan horses and rootkits Disadvantages include the following:

• Penetration testing can cause severe line-management problems without the involvement of senior management.

• Penetration testing is a waste of time if it is the only security measure taken by the company.

• It is very expensive, especially if improperly planned.

• The tester can use the information he ?nds against you.

Who You Should Avoid

Your institution should never enlist a convicted felon to test your security system.

What You Should Tell the Tester

• You should provide your institution’s legal company name and address as well as the name of a contact person who they can always contact (day or night).

• You should also provide the limits and scope of the testing without denying the tester the opportunity to use his creativity. However, you must ensure that you instruct the tester that the testing should not damage anything and to document any problems caused or found.

• You should detail what systems or networks are off-limits and during what hours the testing will take place. Some experts suggest that you handle this like a ?rewall — list what you will allow and prohibit everything else. Be prepared to pay extra for testing at strange hours. Ensure that you have quali?ed employees on site during those strange hours to reboot downed systems.

• You should also indicate if you own the transaction Web site or use an ISP.

• Specify whether you will allow social engineering attacks (deception, trickery, or coercion are at the heart of social engineering techniques). Many testers believe that social engineering attacks may do more harm than good because they affect employee morale. Therefore, you may wish to limit publication of the successful social engineering attacks or redact the names of employees the tester fooled into providing information.

• Specify whether you will allow DoS attacks. If you allow these attacks, schedule them for a non-operations time and have someone babysitting the network while the attack happens. However, never allow distributed denial-of-service attacks, as they involve other companies; they always bring systems down and harm your Internet service provider and all routers in between.

• Specify whether the tester will cover his tracks or leave evidence on the system, such as text messages. The tester should never leave a backdoor program in your system. You may decide that a report of areas where the tester could have entered is suf?cient.

  1. • Specify exactly what the purpose of the test is:

  2. — Is it to get into your system, provide proof of successful entrance, and stop?

  3. — Will the tester place something on your system, such as a ?le or message, as proof that he gained entrance to the system?

  4. — Will you authorize the tester to gain system administrator privileges that allow him unlimited access to accounts?

  5. — Should the tester gain access to ?les or e-mail?

  6. — The tester should collect data indirectly by doing research on the Internet. This is mandatory for a penetration test. The Internet presence measures the footprints your employees leave on the Internet.

• Ask the tester to provide a list of things he or she will do to facilitate the test.

• Will the social engineering attacks be limited strictly to remote attacks, such as phone calls to employees, or will the hacker also conduct them in person? (In-person attacks include reviewing information in trash receptacles, posing as maintenance personnel, service bureau personnel, or employees of the institution, following employees into secured areas (tailgating), etc.) Many experts believe that on-site penetration testing is really auditing. Some companies have their employees perform the on-site social engineering tests in conjunction with the outside tester. Social engineering can also include e-mailing employees or inviting them to visit a certain Web site.

• Require that the tester indicates in his report how he got the data and if he believes your site is secured against the top-20 tools currently available in the wild. Require that he give some examples of how he located these tools and which ones they are. It is not suf?cient that your site is currently safe from the exploits these tools attempt. The tester should measure your network’s response to each tool’s unique signature or method. For example, some tools are poorly written and may accidentally bring down a network, even though that was not the intent of the tool. In this way, you determine if the tester just uses a commercial scanning tool, or if he really tries to hack into your system. Many experts believe that no one tool is more than 10 percent effective in penetration testing.

What You Should Not Tell the Tester

You should not provide technical information that a hacker would not know in advance, such as information regarding:

• Firewalls

• Routers

• Filters

• Concentrators

• Con?guration rules

What You Should Do before You Finalize the Contract

• 1. • You should determine the vendor’s policy on hiring:

  2. — Obtain proof of liability insurance

  3. — How long has the testing company been in business?

  4. — How long has the testing team been together?

  5. — Ask for a description of the vendor’s testing procedures. Avoid vendors who will not explain their entire testing procedure.

• Ask the vendor how you will reach them during the testing process. Avoid vendors you cannot reach at any time during the test.

• Ask the vendors about the dangers of denial-of-service attacks. Avoid vendors who encourage denial-of-service attacks without telling you how dangerous they are.

• Ask for and insist on merit examples of past work.

• Ask the vendor for redacted examples of his ?nal product. Avoid a vendor who will not supply speci?c examples of his ?nal product.

• Demand that the vendor sign a nondisclosure agreement. Avoid vendors who refuse to do so.

• Avoid vendors who offer refunds on security tests in cases of “secure networks.” Professional security testers operate as a service and will not offer refunds in most every case.

• Have your contract reviewed by your attorney before signing.

• Require copies of ?les and data that the tester is able to access during the attacks. Specify whether these outputs will be paper or digital. Ask for traf?c dumps, logs, and raw data. The tester should also provide the IP address from which the test is coming.

What You Should Tell Your Staff

Try to limit the number of employees who know about the test to the technicians responsible for the networks and computer systems. Assign one employee as the Internal Trusted Agent (ITA). The tester and ITA will communicate with each other if needed during the test. Your employees should know that automated intrusion detection systems block out the tester’s IP after a few seconds of scanning. They should not assume that all activity is part of the test. You could actually be under attack from a hacker. Ensure that the technicians know a scan is coming and from where.

What the Tester Should Provide at the Conclusion of the Test

The tester should provide both a brief executive summary (one or two pages) indicating test results, and a detailed listing of all ?ndings and results and what methodology of attacks he used. He should indicate what weaknesses he found and include recommendations for improvement. He should write his report so that nontechnical people understand it. At a minimum, the report should include the following items:

• What could be tested

• What was tested

• When and from where the test happened

• The performance effects on the test, and vice versa

• A detailed executive summary in nontechnical terms that includes the good and bad

• The tools used for ?ndings

• Information security ?ndings

• Holes, bugs, and miscon?gurations in technical detail with suggestions on ?xing them

• Network map

• Any weaknesses discovered

• Passwords and logins discovered

• Speci?c ?rewall/router behavior ?ndings against a list of attacks (not tools)

Your next move depends on his ?ndings. If he ?nds many problems, you should begin by ?xing the problems. You should also:

• Review all security policies and procedures.

• Ensure staff is trained in security.

• Determine if you need to conduct a full security assessment.

• Review corporate and disaster recovery planning.

Notes

1. The Open Source Security Testing Methodology Manual, by Peter Herzog, http:/www.isecom.com.

Acknowledgments

Many industry experts contributed to this chapter. Thanks to Chris Hare of Nortel Networks and Mike Hines of Purdue University. I am very grateful to those who made signi?cant contributions. Hal Tipton of HFT Associates in Villa Park, California, and author of numerous IT security books; Clement Dupuis of CGI in Canada and moderator of the CISSP Open Study Guide Web Site; and Pete Herzog, moderator of the Open Source Security Testing Methodology Forum.

The contents of this document are my own and do not represent those of any government agency.

Tags: Information Security, Information System Audit

Posted in Information System Audit | No Comments »

The Self-Hack Audit

Saturday, July 31st, 2010

Stephen James

Payoff

As organizations continue to link their internal networks to the Internet, system managers and administrators are becoming increasingly aware of the need to secure their systems. The self-hack audit (SHA) is an approach that uses hacker methods to identify and eliminate security weaknesses in a network before they are discovered by a hacker. This article describes the most common hacker techniques that have allowed unauthorized persons to gain access to computer resources and provides steps for network administrators to improve network security.

Introduction

In today’s electronic environment, the threat of being hacked is no longer an unlikely incident, occurring in a few unfortunate organizations. New reports of hacker incidents and compromised systems appear almost daily. As organizations continue to link their internal networks to the Internet, system managers and administrators are becoming increasingly aware of the need to secure their systems. Implementing basic password controls is no longer adequate to guard against unauthorized access to data. Organizations are now looking for more up-to-date techniques to assess and secure their systems. The most popular and practical technique emerging is the self-hack audit (SHA). The SHA is an approach that uses hacker methods to identify and eliminate security weaknesses in a network before they are discovered by a hacker.

This article provides a methodology for the SHA and presents a number of popular hacker techniques that have allowed hackers to penetrate various systems in the past. Each description is followed by a number of suggested system administration steps or precautions that should be followed to help prevent such attacks. Although some of the issues discussed are specific to UNIX systems, the concepts can be applied to all systems in general.

Objectives of the Self-Hack Audit

The basic objective of the SHA is to identify all potential control weaknesses that may allow unauthorized persons to gain access to the system. The network administrator must be familiar and use all known hacker techniques for overcoming system security. Depending on the nature of the audit, the objective may be either to extend a user’s current levels of access (which may be no access)or to destroy (i.e., sabotage) the system.

Overview of the Self-Hack Audit Methodology

To perform a useful SHA, the different types of hackers must be identified and understood. The stereotype of a hacker as a brilliant computer science graduate sitting in a laboratory in a remote part of the world is a dangerous misconception. Although such hackers exist, the majority of security breaches are performed by staff members of the breached organization. Hackers can be categorized into four types:

· Persons within an organization who are authorized to access the system. An example

may be a legitimate staff member in the Accounting department who has access to

Accounts Payable application menu functions.

· Persons within an organization who are not authorized to access the system. These individuals may include personnel such as the cleaning staff.

· Persons outside an organization who are authorized to access the system. An example may be a remote system support person from the organization’s software vendor.

· Persons outside an organization who are not authorized to access the system. An

example is an Internet user in an overseas country who has no connection with the

organization.

The objective of the SHA is to use any conceivable method to compromise system security. Each of the four hacker types must be considered to assess fully all potential security exposures.

Popular Hacker Techniques

The following sections describe the techniques most commonly used by hackers to gain access to various corporate systems. Each section discusses the hacker technique and proposes basic controls that can be implemented to help mitigate these risks. The network administrator should attempt each of these techniques and should tailor the procedures to suit the organization’s specific environment.

Accessing the Log-in Prompt

One method of gaining illegal access to a computer system is through the Log-in prompt. This situation may occur when the hacker is physically within the facility or is attempting to access the system through a dial-in connection.

Physical Access.

An important step in securing corporate information systems is to ensure that physical access to computer resources is adequately restricted. Any internal or external person who gains physical access to a terminal is given the opportunity to attempt to sign on at the log-in prompt.

To reduce the potential for unauthorized system access by way of a terminal within the organization’s facility, the network administrator should ensure that:

· Terminals are located in physically secure environments.

· Appropriate access control devices are installed on all doors and windows that may be used to access areas where computer hardware is located.

· Personal computers that are connected to networks are password-protected if they are

located in unrestricted areas. A hacker trying to access the system would be required to

guess a legitimate password before gaining access through the log-in prompt.

· Users do not write their passwords on or near their work areas.

Dial-in Access.

Another method of accessing the log-in prompt is to dial in to the host. Many “daemon dialers” are readily available on the Internet. These programs, when given a range of numbers to dial, can identify valid modem numbers. Once a hacker discovers an organization’s modem number, he or she can dial in and, in most cases, immediately gain access to the log-in prompt.

To minimize the potential for security violations by way of dial-in network access, the network administrator should ensure that:

· Adequate controls are in place for dial-in sessions, such as switching off the modem

when not in use, using a call-back facility, or requiring an extra level of authentication,

such as a one-time password, for dial-in sessions.

· The organization’s logo and name are removed from the log-in screen so that the hacker does not know which system has been accessed.

· A warning message alerts unauthorized persons that access to the system is an offense and that their activities may be logged. This is a legal requirement in some countries.

Obtaining Passwords

Once the hacker has gained access to an organization’s log-in prompt, he or she can attempt to sign on to the system. This procedure requires a valid user ID and password combination.

Brute Force Attacks.

Brute force attacks involve manual or automated attempts to guess valid passwords. A simple password guessing program can be written in approximately 60 lines of C code or 40 lines of PERL. Many password guessing programs are available on the Internet. Most hackers have a “password hit list,” which is a collection of default passwords automatically assigned to various system accounts whenever they are installed. For example, the default password for the guest account in most UNIX systems is “guest.”

To protect the network from unauthorized access, the network administrator should ensure that:

· All user accounts are password protected.

· Password values are appropriately selected to avoid guessing.

· Default passwords are changed once the system is installed.

· Failed log-in attempts are logged and followed up appropriately.

· User accounts are locked out after a predefined number of sign-on failures.

· Users are forced to select passwords that are difficult to guess.

· Users are forced to change their passwords periodically throughout the year.

· Unused user accounts are disabled.

· Users are educated and reminded regularly about the importance of proper password management and selection.

Password Cracking.

Most UNIX sites store encrypted passwords together with corresponding user accounts in a file called /etc/passwd. Should a hacker gain access to this file, he or she can simply run a password cracking program such as Crack. Crack works by encrypting a standard dictionary with the same encryption algorithm used by UNIX systems (called crypt). It then compares each encrypted dictionary word against the entries in the password file until it finds a match. Crack is freely available via an anonymous File Transfer Protocol from ftp.cert.org at/pub/tools/crack.

To combat the hacker’s use of password-cracking software, the network administrator should ensure that:

· Encrypted passwords are stored in a shadow password file and that the file is adequately protected.

· All “weak” passwords are identified by running Crack against the password file.

· Software such as Npasswd or Passwd+ is used to force users to select passwords that are difficult to guess.

· Users do not write their passwords on or near their work environments.

·Only the minimum number of users have access to the command line to minimize the risk of copying the /etc/passwdfile.

Keystroke Logging.

It takes less than 30 seconds to type in a short script to capture sign-on sessions. A hacker can use a diskette to install a keystroke-logging program onto a workstation. Once this Trojan Horse is installed, it works in the background and captures every sign-on session, based on trigger key words. The hacker can read the captured keystrokes from a remote location and gain access to the system. This technique is very simple and almost always goes unnoticed.

To prevent a hacker’s access to the system by way of a keystroke-logging program, the network administrator should ensure that:

· Privileged accounts (e.g., root) require one-time passwords.

· The host file system and individual users’ workstations are periodically scanned for Trojan Horses that could include keystroke-logging programs.

· Adequate physical access restrictions to computer hardware are in place to prevent persons from loading Trojan Horses.

Packet Sniffing.

The Internet offers a wide range of network monitoring tools, including network analyzers and “packet sniffers.” These tools work by capturing packets of data as they are transmitted along a communications segment. Once a hacker gains physical access to a PC connected to a LAN and loads this software, he or she is able to monitor data as it is transferred between locations. Alternatively, the hacker can attach a laptop to a network port in the office and capture data packets.

Remembering that network traffic often is not encrypted, there is a high chance that the hacker will capture valid user account and password combinations, especially between the hours of 8:00 a.m. and 9:00 a.m. Tcpdump is a tool for UNIX systems used to monitor network traffic and is freely available via an anonymous FTP from ftp.ee.lbl.gov at tcpdump2.2.1.tar.z.

To reduce the possibility of account and password leaks through packet sniffers, the network administrator should ensure that:

· Communications lines are segmented as much as practical.

· Sign-on sessions and other sensitive data are transmitted in an encrypted format by using software such as Kerberos.

· Privileged accounts (e.g., root) sign on using one-time passwords.

· Physical access to communications lines and computer hardware is restricted.

Social Engineering.

Hackers often select a user account that has not been used for a period of time (typically about two weeks) and ensure that it belongs to a user whom the administrator is not likely to recognize by voice. Hackers typically target accounts that belong to interstate users or users in another building. Once they have chosen a target, they assume a user’s identity and call the administrator or the help desk, explaining that they have forgotten their passwords. In most cases, the administrator or help desk will reset passwords for the hackers over the telephone.

In an effort to keep the network safe from this type of infiltration, the network administrator should ensure that:

· All staff are regularly reminded and educated about the importance of data security and about proper password management.

· The organization has documented and controlled procedures for resetting passwords over the telephone.

· Staff do not fall prey to social engineering attacks. Staff members must be aware of the

possibility that a hacker may misrepresent himself or herself as a member of the

information systems department and ask for a password.

General Access Methods

Hackers use a variety of methods to gain access to a host system from another system.

Internet Protocol Address Spoofing.

In a typical network, a host allows other “trusted” hosts to communicate with it without requiring authentication (i.e., without requiring a user account and password combination). Hosts are identified as trusted by configuring files such as the .rhost and /etc/hosts.equiv files. Any host other than those defined as trusted must provide authentication before it is allowed to establish communication links.

Internet protocol (IP) spoofing involves an untrusted host connecting to the network and pretending to be a trusted host. This access is achieved by the hacker changing its IP number to that of a trusted host. In other words, the intruding host fools the host on the local network into not challenging it for authentication.

To avoid this type of security violation, the network administrator should ensure that:

· Firewalls and routers are appropriately configured so that they reject IP spoofing attacks.

·Only appropriate hosts are defined as trusted within /etc/hosts.equiv, and file permissions over this file are adequate.

·Only appropriate hosts are defined within users’ /.rhost files. If practical, these files should be removed.

Unattended Terminals.

It is quite common to find user terminals left signed on and unattended for extended periods of time, such as during lunch time. Assuming that the hacker can gain physical access to users’ work areas (or assuming that the hacker is an insider), this situation is a perfect opportunity for a hacker to compromise the system’s security. A hacker may use an unattended terminal to process unauthorized transactions, insert a Trojan Horse, download a destructive virus, modify the user’s .rhost file, or change the user’s password so that the hacker can sign on later.

The network administrator can minimize the threat from access through unattended terminals by ensuring that:

· User sessions are automatically timed out after a predefined period of inactivity, or password protected screen savers are invoked.

· Users are regularly educated and reminded about the importance of signing off their sessions whenever they expect to leave their work areas unattended.

· Adequate controls are in place to prevent unauthorized persons from gaining physical access to users’ work areas.

Writeable Set User ID Files.

UNIX allows executable files to be granted root privileges by making file permissions set user ID (SUID) root. Hackers often search through the file system to identify all SUID files and to determine whether they are writeable. Should they be writeable, the hacker can insert a simple line of code within the SUID program so that the next time it is executed, it will write to the /etc/passwd file and this will enable the hacker to gain root privileges. The following UNIX command will search for SUID root files throughout the entire file system: find / -user root -perm -4000 -print

The network administrator can reduce the possibility of illegal access through SUID files by ensuring that:

· Only the minimum number of programs are assigned SUID file permissions.

· Programs that are SUID are not writeable by users other than root.

· Executables defined within the system cron tables (especially the root cron table) are not writeable by users other than root because they are effectively SUID root.

Computer Emergency Response Team Advisories.

The Computer Emergency Response Team (CERT)issues advisories whenever a new security exposure has been identified. These exposures often allow unauthorized users to gain root access to systems. Hackers always keep abreast of the latest CERT advisories to identify newly found bugs in system software. CERT can be accessed via an anonymous FTP at info.cert.org.

The network administrator should ensure that:
·	All CERT advisories have been reviewed and acted on in a controlled and timely manner.
·	Checksums are used to ensure the integrity of CERT patches before they are implemented.
	Hacker Bulletin Boards. The Internet has a large number of hacker bulletin boards and forums that act as an

invaluable source of system security information. The most popular hacker bulletin board is the “2600” discussion group. Hackers from around the world exchange security information relating to various systems and often publish security sensitive information relating to specific organizations or hacker techniques relating to specific programs.

The network administrator should ensure that the organization’s data security officer regularly reviews hacker bulletin boards to identify new techniques and information that may be relevant to the organization’s system environment.

Internet Software.

The Internet offers a large number of useful tools, such as SATAN, COPS, and ISS, which can assist data security officers and administrators in securing computer resources. These tools scan corporate systems to identify security exposures. However, these tools are also available to hackers and can assist them in penetrating systems.

To identify and resolve potential security problems, the network administrator should ensure that:

· The latest version of each security program is obtained and run in a regular manner. Each identified exposure should be promptly resolved.

· The system is subject to regular security audits by both the data security officer and independent external consultants.

Conclusion

Hacker activity is a real and ongoing threat that will continue to increase as businesses connect their internal corporate networks to the Internet. This article has described the most common hacker techniques that have allowed unauthorized persons to gain access to computer resources. The self-hack audit is becoming an increasingly critical technique for identifying security weaknesses that, if not detected and resolved in a timely manner, could allow hackers to penetrate the corporate system. System administrators and data security officers should keep abreast of the latest hacker techniques by regularly reading all CERT publications and hacker bulletin boards.

Author Biographies

Stephen James

Stephen James is one of Australia’s leading computer security experts, specializing in UNIX and Internet security as well as hacker studies. He is a senior consultant with Price Waterhouse (Sydney).

Tags: Information Security, Information System Audit

Posted in Information System Audit | No Comments »

Penetration Testing

Saturday, July 31st, 2010

Stephen D. Fried, CISSP

This chapter provides a general introduction to the subject of penetration testing and provides the security professional with the background needed to understand this special area of security analysis. Penetration testing can be a valuable tool for understanding and improving the security of a computer or network. However, it can also be used to exploit system weaknesses and attack systems and steal valuable information. By under-standing the need for penetration testing, and the issues and processes surrounding its use, a security profes-sional will be better able to use penetration testing as a standard part of the analysis toolkit.

This chapter presents penetration testing in terms of its use, application, and process. It is not intended as an in-depth guide to speci?c techniques that can be used to test penetration-speci?c systems. Penetration testing is an art that takes a great deal of skill and practice to do effectively. If not done correctly and carefully, the penetration test can be deemed invalid (at best) and, in the worst case, actually damage the target systems. If the security professional is unfamiliar with penetration testing tools and techniques, it is best to hire or contract someone with a great deal of experience in this area to advise and educate the security staff of an organization.

What is Penetration Testing?

Penetration testing is de?ned as a formalized set of procedures designed to bypass the security controls of a system or organization for the purpose of testing that system’s or organization’s resistance to such an attack. Penetration testing is performed to uncover the security weaknesses of a system and to determine the ways in which the system can be compromised by a potential attacker. Penetration testing can take several forms (which will be discussed later) but, in general, a test consists of a series of “attacks” against a target. The success or failure of the attacks, and how the target reacts to each attack, will determine the outcome of the test.

The overall purpose of a penetration test is to determine the subject’s ability to withstand an attack by a hostile intruder. As such, the tester will be using the tricks and techniques a real-life attacker might use. This simulated attack strategy allows the subject to discover and mitigate its security weak spots before a real attacker discovers them.

The reason penetration testing exists is that organizations need to determine the effectiveness of their security measures. The fact that they want tests performed indicates that they believe there might be (or want to discover) some de?ciency in their security. However, while the testing itself might uncover problems in the organization’s security, the tester should attempt to discover and explain the underlying cause of the lapses in security that allowed the test to succeed. Simply stating that the tester was able to walk out of a building with sensitive information is not suf?cient. The tester should explain that the lapse was due to inadequate attention by the guard on duty or a lack of guard staff training that would enable them to recognize valuable or sensitive information.

There are three basic requirements for a penetration test. First, the test must have a de?ned goal and that goal should be clearly documented. The more speci?c the goal, the easier it will be to recognize the success or failure of the test. A goal such as “break into the XYZ corporate network,” while certainly attainable, is not as precise as “break into XYZ’s corporate network from the Internet and gain access to the research department’s ?le server.” Each test should have a single goal. If the tester wishes to test several aspects of security at a business

or site, several separate tests should be performed. This will enable the tester to more clearly distinguish between successful tests and unsuccessful attempts.

The test should have a limited time period in which it is to be performed. The methodology in most penetration testing is to simulate the types of attacks that will be experienced in the real world. It is reasonable to assume that an attacker will expend a ?nite amount of time and energy trying to penetrate a site. That time may range from one day to one year or beyond; but after that time is reached, the attacker will give up. In addition, the information being protected may have a ?nite useful “lifetime.” The penetration test should acknowledge and accept this fact. Thus, part of the goal statement for the test should include a time limit that is considered reasonable based on the type of system targeted, the expected level of the threat, and the lifetime of the information.

Finally, the test should have the approval of the management of the organization that is the subject of the test. This is extremely important, as only the organization’s management has the authority to permit this type of activity on its network and information systems.

Terminology

There are several terms associated with penetration testing. These terms are used throughout this chapter to describe penetration testing and the people and events involved in a penetration test.

The tester is the person or group who is performing the penetration test. The purpose of the tester is to plan and execute the penetration test and analyze the results for management. In many cases, the tester will be a member of the company or organization that is the subject of the test. However, a company may hire an outside ?rm to conduct the penetration test if it does not have the personnel or the expertise to do it itself.

An attacker is a real-life version of a tester. However, where the tester works with a company to improve its security, the attacker works against a company to steal information or resources.

An attack is the series of activities performed by the tester in an attempt to circumvent the security controls of a particular target. The attack may consist of physical, procedural, or electronic methods.

The subject of the test is the organization upon whom the penetration test is being performed. The subject can be an entire company or it can be a smaller organizational unit within that company.

A target of a penetration test is the system or organization that is being subjected to a particular attack at any given time. The target may or may not be aware that it is being tested. In either case, the target will have a set of defenses it presents to the outside world to protect itself against intrusion. It is those defenses that the penetration test is designed to test. A full penetration test usually consists of a number of attacks against a number of different targets.

Management is the term used to describe the leadership of an organization involved in the penetration test. There may be several levels of management involved in any testing effort, including the management of the speci?c areas of the company being tested, as well as the upper management of the company as a whole. The speci?c levels of management involved in the penetration testing effort will have a direct impact on the scope of the test. In all cases, however, it is assumed that the tester is working on behalf of (and sponsored by) at least one level of management within the company.

The penetration test (or, more simply, the test) is the actual performance of a simulated attack on the target.

Why Test?

There are several reasons why an organization will want a penetration test performed on its systems or operations. The ?rst (and most prevalent) is to determine the effectiveness of the security controls the orga-nization has put into place. These controls may be technical in nature, affecting the computers, network, and information systems of the organization. They may be operational in nature, pertaining to the processes and procedures a company has in place to control and secure information. Finally, they may be physical in nature. The tester may be trying to determine the effectiveness of the physical security a site or company has in place. In all cases, the goal of the tester will be to determine if the existing controls are suf?cient by trying to get around them.

The tester may also be attempting to determine the vulnerability an organization has to a particular threat. Each system, process, or organization has a particular set of threats to which it feels it is vulnerable. Ideally, the organization will have taken steps to reduce its exposure to those threats. The role of the tester is to determine the effectiveness of these countermeasures and to identify areas for improvement or areas where additional countermeasures are required. The tester may also wish to determine whether the set of threats the organization has identi?ed is valid and whether or not there are other threats against which the organization might wish to defend itself.

A penetration test can sometimes be used to bolster a company’s position in the marketplace. A test, executed by a reputable company and indicating that the subject’s environment withstood the tester’s best efforts, can be used to give prospective customers the appearance that the subject’s environment is secure. The word “appearance” is important here because a penetration test cannot examine all possible aspects of the subject’s environment if it is even moderate in size. In addition, the security state of an enterprise is constantly changing as new technology replaces old, con?gurations change, and business needs evolve. The “environment” the tester examines may be very different from the one the customer will be a part of. If a penetration test is used as proof of the security of a particular environment for marketing purposes, the customer should insist on knowing the details, methodology, and results of the test.

A penetration test can be used to alert the corporation’s upper management to the security threat that may exist in its systems or operations. While the general knowledge that security weaknesses exist in a system, or speci?c knowledge of particular threats and vulnerabilities may exist among the technical staff, this message may not always be transmitted to management. As a result, management may not fully understand or appreciate the magnitude of the security problem. A well-executed penetration test can systematically uncover vulnera-bilities that management was unaware existed. The presentation of concrete evidence of security problems, along with an analysis of the damage those problems can cause to the company, can be an effective wake-up call to management and spur them into paying more attention to information security issues. A side effect of this wake-up call may be that once management understands the nature of the threat and the magnitude to which the company is vulnerable, it may be more willing to expend money and resources to address not only the security problems uncovered by the test but also ancillary security areas needing additional attention by the company. These ancillary issues may include a general security awareness program or the need for more funding for security technology. A penetration test that uncovers moderate or serious problems in a company’s security can be effectively used to justify the time and expense required to implement effective security programs and countermeasures.

Types of Penetration Testing

The typical image of a penetration test is that of a team of high-tech computer experts sitting in a small room attacking a company’s network for days on end or crawling through the ventilation shafts to get into the company’s “secret room.” While this may be a glamorous image to use in the movies, in reality the penetration test works in a variety of different (and very nonglamorous) ways.

The ?rst type of testing involves the physical infrastructure of the subject. Very often, the most vulnerable parts of a company are not found in the technology of its information network or the access controls found in its databases. Security problems can be found in the way the subject handles its physical security. The penetration tester will seek to exploit these physical weaknesses. For example, does the building provide adequate access control? Does the building have security guards, and do the guards check people as they enter or leave a building? If intruders are able to walk unchecked into a company’s building, they will be able to gain physical access to the information they seek. A good test is to try to walk into a building during the morning when everyone is arriving to work. Try to get in the middle of a crowd of people to see if the guard is adequately checking the badges of those entering the building.

Once inside, check if sensitive areas of the building are locked or otherwise protected by physical barriers. Are ?le cabinets locked when not in use? How dif?cult is it to get into the communications closet where all the telephone and network communication links terminate? Can a person walk into employee of?ce areas unaccompanied and unquestioned? All the secure and sensitive areas of a building should be protected against unauthorized entry. If they are not, the tester will be able to gain unrestricted access to sensitive company information.

While the physical test includes examining protections against unauthorized entry, the penetration test might also examine the effectiveness of controls prohibiting unauthorized exit. Does the company check for theft of sensitive materials when employees exit the facility? Are laptop computers or other portable devices registered and checked when entering and exiting the building? Are security guards trained not only on what types of equipment and information to look for, but also on how equipment can be hidden or masked and why this procedure is important?

Another type of testing examines the operational aspects of an organization. Whereas physical testing investigates physical access to company computers, networks, or facilities, operational testing attempts to determine the effectiveness of the operational procedures of an organization by attempting to bypass those procedures. For example, if the company’s help desk requires each user to give personal or secret information before help can be rendered, can the tester bypass those controls by telling a particularly believable “sob story” to the technician answering the call? If the policy of the company is to “scramble” or demagnetize disks before disposal, are these procedures followed? If not, what sensitive information will the tester ?nd on disposed disks and computers? If a company has strict policies concerning the authority and process required to initiate ID or password changes to a system, can someone simply claiming to have the proper authority (without any actual proof of that authority) cause an ID to be created, removed, or changed? All these are attacks against the operational processes a company may have, and all of these techniques have been used successfully in the past to gain entry into computers or gain access to sensitive information.

The ?nal type of penetration test is the electronic test. Electronic testing consists of attacks on the computer systems, networks, or communications facilities of an organization. This can be accomplished either manually or through the use of automated tools. The goal of electronic testing is to determine if the subject’s internal systems are vulnerable to an attack through the data network or communications facilities used by the subject.

Depending on the scope and parameters of a particular test, a tester may use one, two, or all three types of tests. If the goal of the test is to gain access to a particular computer system, the tester may attempt a physical penetration to gain access to the computer’s console or try an electronic test to attack the machine over the network. If the goal of the test is to see if unauthorized personnel can obtain valuable research data, the tester may use operational testing to see if the information is tracked or logged when accessed or copied and determine who reviews those access logs. The tester may then switch to electronic penetration to gain access to the computers where the information is stored.

What Allows Penetration Testing to Work?

There are several general reasons why penetration tests are successful. Many of them are in the operational area; however, security problems can arise due to de?ciencies in any of the three testing areas.

A large number of security problems arise due to a lack of awareness on the part of a company’s employees of the company’s policies and procedures regarding information security and protection. If employees and contractors of a company do not know the proper procedures for handling proprietary or sensitive information, they are much more likely to allow that information to be left unprotected. If employees are unaware of the company policies on discussing sensitive company information, they will often volunteer (sometimes unknow-ingly) information about their company’s future sales, marketing, or research plans simply by being asked the right set of questions. The tester will exploit this lack of awareness and modify the testing procedure to account for the fact that the policies are not well-known.

In many cases, the subjects of the test will be very familiar with the company’s policies and the procedures for handling information. Despite this, however, penetration testing works because often people do not adhere to standardized procedures de?ned by the company’s policies. Although the policies may say that system logs should be reviewed daily, most administrators are too busy to bother. Good administrative and security practices require that system con?gurations should be checked periodically to detect tampering, but this rarely happens. Most security policies indicate minimum complexities and maximum time limits for passwords, but many systems do not enforce these policies. Once the tester knows about these security procedural lapses, they become easy to exploit.

Many companies have disjointed operational procedures. The processes in use by one organization within a company may often con?ict with the processes used by another organization. Do the procedures used by one application to authenticate users complement the procedures used by other applications, or are there different standards in use by different applications? Is the access security of one area of a company’s network lower than that of another part of the network? Are log ?les and audit records reviewed uniformly for all systems and services, or are some systems monitored more closely than others? All these are examples of a lack of coordination between organizations and processes. These examples can be exploited by the tester and used to get closer to the goal of the test. A tester needs only to target the area with the lower authentication standards, the lower access security, or the lower audit review procedures in order to advance the test.

Many penetration tests succeed because people often do not pay adequate attention to the situations and circumstances in which they ?nd themselves. The hacker’s art of social engineering relies heavily on this fact. Social engineering is a con game used by intruders to trick people who know secrets into revealing them. People who take great care in protecting information when at work (locking it up or encrypting sensitive data, for example) suddenly forget about those procedures when asked by an acquaintance at a party to talk about their work. Employees who follow strict user authentication and system change control procedures suddenly “forget” all about them when they get a call from the “Vice President of Such and Such” needing something done “right away.” Does the “Vice President” himself usually call the technical support line with problems? Probably not, but people do not question the need for information, do not challenge requests for access to sensitive information even if the person asking for it does not clearly have a need to access that data, and do not compare the immediate circumstances with normal patterns of behavior.

Many companies rely on a single source for enabling an employee to prove identity, and often that source has no built-in protection. Most companies assign employee identi?cation (ID) numbers to their associates. That number enables access to many services the company has to offer, yet is displayed openly on employee badges and freely given when requested. The successful tester might determine a method for obtaining or generating a valid employee ID number in order to impersonate a valid employee.

Many hackers rely on the anonymity that large organizations provide. Once a company grows beyond a few hundred employees, it becomes increasingly dif?cult for anyone to know all employees by sight or by voice. Thus, the IT and HR staff of the company need to rely on other methods of user authentication, such as passwords, key cards, or the above-mentioned employee ID number. Under such a system, employees become anonymous entities, identi?ed only by their ID number or their password. This makes it easier to assume the identity of a legitimate employee or to use social engineering to trick people into divulging information. Once the tester is able to hide within the anonymous structure of the organization, the fear of discovery is reduced and the tester will be in a much better position to continue to test.

Another contributor to the successful completion of most penetration tests is the simple fact that most system administrators do not keep their systems up-to-date with the latest security patches and ?xes for the systems under their control. A vast majority of system break-ins occur as a result of exploitation of known vulnerabilities — vulnerabilities that could have easily been eliminated by the application of a system patch, con?guration change, or procedural change. The fact that system operators continue to let systems fall behind in security con?guration means that testers will continuously succeed in penetrating their systems.

The tools available for performing a penetration test are becoming more sophisticated and more widely distributed. This has allowed even the novice hacker to pick up highly sophisticated tools for exploiting system weaknesses and applying them without requiring any technical background in how the tool works. Often these tools can try hundreds of vulnerabilities on a system at one time. As new holes are found, the hacker tools exploit them faster than the software companies can release ?xes, making life even more miserable for the poor administrator who has to keep pace. Eventually, the administrator will miss something, and that something is usually the one hole that a tester can use to gain entry into a system.

Basic Attack Strategies

Every security professional who performs a penetration test will approach the task somewhat differently, and the actual steps used by the tester will vary from engagement to engagement. However, there are several basic strategies that can be said to be common across most testing situations.

First, do not rely on a single method of attack. Different situations call for different attacks. If the tester is evaluating the physical security of a location, the tester may try one method of getting in the building; for example walking in the middle of a crowd during the morning inrush of people. If that does not work, try following the cleaning people into a side door. If that does not work, try something else. The same method holds true for electronic attacks. If one attack does not work (or the system is not susceptible to that attack), try another.

Choose the path of least resistance. Most real attackers will try the easiest route to valuable information, so the penetration tester should use this method as well. If the test is attempting to penetrate a company’s network, the company’s ?rewall might not be the best place to begin the attack (unless, of course, the ?rewall was the stated target of the test) because that is where all the security attention will be focused. Try to attack lesser-guarded areas of a system. Look for alternate entry points; for example, connections to a company’s business partners, analog dial-up services, modems connected to desktops, etc. Modern corporate networks have many more connection points than just the ?rewall, so use them to the fullest advantage. Feel free to break the rules. Most security vulnerabilities are discovered because someone has expanded the limits of a system’s capabilities to the point where it breaks, thus revealing a weak spot in the system. Unfor-tunately, most users and administrators concentrate on making their systems conform to the stated policies of the organization. Processes work well when everyone follows the rules, but can have unpredictable results when those rules are broken or ignored. Therefore, when performing a test attack, use an extremely long password; enter a 1000-byte URL into a Web site; sign someone else’s name into a visitors log; try anything that represents abnormality or nonconformance to a system or process. Real attackers will not follow the rules of the subject system or organization — nor should the tester.

Do not rely exclusively on high-tech, automated attacks. While these tools may seem more “glamorous” (and certainly easier) to use, they may not always reveal the most effective method of entering a system. There are a number of “low-tech” attacks that, while not as technically advanced, may reveal important vulnerabilities and should not be overlooked. Social engineering is a prime example of this type of approach. The only tools required to begin a social engineering attack are the tester’s voice, a telephone, and the ability to talk to people. Yet despite the simplicity of the method (or, perhaps, because of it), social engineering is incredibly effective as a method of obtaining valuable information.

“Dumpster diving” can also be an effective low-tech tool. Dumpster diving is a term used to describe the act of searching through the trash of the subject in an attempt to ?nd valuable information. Typical information found in most Dumpsters includes old system printouts, password lists, employee personnel information, drafts of reports, and old fax transmissions. While not nearly as glamorous as running a port scan on a subject’s computer, it also does not require any of the technical skill that port scanning requires. Nor does it involve the personal interaction required of social engineering, making it an effective tool for testers who may not be highly skilled in interpersonal communications.

One of the primary aims of the penetration tester is to avoid detection. The basic tenet of penetration testing is that information can be obtained from a subject without his or her knowledge or consent. If a tester is caught in the act of testing, this means, by de?nition, that the subject’s defenses against that particular attack scenario are adequate. Likewise, the tester should avoid leaving “?ngerprints” that can be used to detect or trace an attack. These ?ngerprints include evidence that the tester has been working in and around a system. The ?ngerprints can be physical (e.g., missing reports, large photocopying bills) or they can be virtual (e.g., system logs detailing access by the tester, or door access controls logging entry and exit into a building). In either case, ?ngerprints can be detected and detection can lead to a failure of the test.

Do not damage or destroy anything on a system unless the destruction of information is de?ned as part of the test and approved (in writing) by management. The purpose of a penetration test is to uncover ?aws and weaknesses in a system or process — not to destroy information. The actual destruction of company infor-mation not only deprives the company of its (potentially valuable) intellectual property, but it may also be construed as unethical behavior and subject the tester to disciplinary or legal action. If the management of the organization wishes the tester to demonstrate actual destruction of information as part of the test, the tester should be sure to document the requirement and get written approval of the management involved in the test. Of course, in the attempt to “not leave ?ngerprints,” the tester might wish to alter the system logs to cover the tester’s tracks. Whether or not this is acceptable is an issue that the tester should discuss with the subject’s management before the test begins.

Do not pass up opportunities for small incremental progress. Most penetration testing involves the appli-cation of many tools and techniques in order to be successful. Many of these techniques will not completely expose a weakness in an organization or point to a failure of an organization’s security. However, each of these techniques may move the tester closer and closer to the ?nal goal of the test. By looking for a single weakness or vulnerability that will completely expose the organization’s security, the tester may overlook many important, smaller weaknesses that, when combined, are just as important. Real-life attackers can have in?nite patience; so should the tester.

Finally, be prepared to switch tactics. Not every test will work, and not every technique will be successful. Most penetration testers have a standard “toolkit” of techniques that work on most systems. However, different systems are susceptible to different attacks and may call for different testing measures. The tester should be prepared to switch to another method if the current one is not working. If an electronic attack is not yielding the expected results, switch to a physical or operational attack. If attempts to circumvent a company’s network connectivity are not working, try accessing the network through the company’s dial-up connections. The attack that worked last time may not be successful this time, even if the subject is the same company. This may either be because something has changed in the target’s environment or the target has (hopefully) learned its lesson from the last test. Finally, unplanned opportunities may present themselves during a test. Even an unsuccessful penetration attempt may expose the possibility that other types of attack may be more successful. By remaining ?exible and willing to switch tactics, the tester is in a much better position to discover system weaknesses.

Planning the Test

Before any penetration testing can take place, a clear testing plan must be prepared. The test plan will outline the goals and objectives of the test, detail the parameters of the testing process, and describe the expectations of both the testing team and the management of the target organization.

The most important part of planning any penetration test is the involvement of the management of the target organization. Penetration testing without management approval, in addition to being unethical, can reasonably be considered “espionage” and is illegal in most jurisdictions. The tester should fully document the testing engagement in detail and get written approval from management before proceeding. If the testing team is part of the subject organization, it is important that the management of that organization knows about the team’s efforts and approves of them. If the testing team is outside the organizational structure and is performing the test “for hire,” the permission of management to perform the test should be included as part of the contract between the testing organization and the target organization. In all cases, be sure that the management that approves the test has the authority to give such approval. Penetration testing involves attacks on the security infrastructure of an organization. This type of action should not be approved or undertaken by someone who does not clearly have the authority to do so.

By de?nition, penetration testing involves the use of simulated attacks on a system or organization with the intent of penetrating that system or organization. This type of activity will, by necessity, require that someone in the subject organization be aware of the testing. Make sure that those with a need to know about the test do, in fact, know of the activity. However, keep the list of people aware of the test to an absolute minimum. If too many people know about the test, the activities and operations of the target may be altered (intentionally or unintentionally) and negate the results of the testing effort. This alteration of behavior to ?t expectations is known as the Hawthorne effect (named after a famous study at Western Electric’s Hawthorne factory whose employees, upon discovering that their behavior was being studied, altered their behavior to ?t the patterns they believed the testers wanted to see.)

Finally, during the course of the test, many of the activities the tester will perform are the very same ones that real-life attackers will use to penetrate systems. If the staff of the target organization discovers these activities, they may (rightly) mistake the test for a real attack and catch the “attacker” in the act. By making sure that appropriate management personnel are aware of the testing activities, the tester will be able to validate the legitimacy of the test.

An important ethical note to consider is that the act of penetration testing involves intentionally breaking the rules of the subject organization in order to determine its security weaknesses. This requires the tester to use many of the same tools and methods that real-life attackers use. However, real hackers sometime break the law or engage in highly questionable behavior in order to carry out their attacks. The security professional performing the penetration test is expected to draw the line between bypassing a company’s security procedures and systems, and actually breaking the law. These distinctions should be discussed with management prior to the commencement of the test, and discussed again if any ethical or legal problems arise during the execution of the test.

Once management has agreed to allow a penetration test, the parameters of the test must be established. The testing parameters will determine the type of test to be performed, the goals of the tests, and the operating boundaries that will de?ne how the test is run. The primary decision is to determine precisely what is being tested. This de?nition can range from broad (“test the ability to break into the company’s network”) to extremely speci?c (“determine the risk of loss of technical information about XYZ’s latest product”). In general, more speci?c testing de?nitions are preferred, as it becomes easier to determine the success or failure of the test. In the case of the second example, if the tester is able to produce a copy of the technical speci?cations, the test clearly succeeded. In the case of the ?rst example, does the act of logging in to a networked system constitute success, or does the tester need to produce actual data taken from the network? Thus, the speci?c criteria for success or failure should be clearly de?ned.

The penetration test plan should have a de?ned time limit. The time length of the test should be related to the amount of time a real adversary can be expected to attempt to penetrate the system and also the reasonable lifetime of the information itself. If the data being attacked has an effective lifetime of two months, a penetration test can be said to succeed if it successfully obtains that data within a two-month window.

The test plan should also explain any limits placed on the test by either the testing team or management. If there are ethical considerations that limit the amount of “damage” the team is willing to perform, or if there are areas of the system or operation that the tester is prohibited from accessing (perhaps for legal or contractual reasons), these must be clearly explained in the test plan. Again, the testers will attempt to act as real-life attackers and attackers do not follow any rules. If management wants the testers to follow certain rules, these must be clearly de?ned. The test plan should also set forth the procedures and effects of “getting caught” during the test. What de?nes “getting caught” and how that affects the test should also be described in the plan.

Once the basic parameters of the test have been de?ned, the test plan should focus on the “scenario” for the test. The scenario is the position the tester will assume within the company for the duration of the test. For example, if the test is attempting to determine the level of threat from company insiders (employees, contractors, temporary employees, etc.), the tester may be given a temporary job within the company. If the test is designed to determine the level of external threat to the organization, the tester will assume the position of an “outsider.” The scenario will also de?ne the overall goal of the test. Is the purpose of the test a simple penetration of the company’s computers or facilities? Is the subject worried about loss of intellectual property via physical or electronic attacks? Are they worried about vandalism to their Web site, fraud in their electronic commerce systems, or protection against denial-of-service attacks? All these factors help to determine the test scenario and are extremely important in order for the tester to plan and execute an effective attack.

Performing the Test

Once all the planning has been completed, the test scenarios have been established, and the tester has deter-mined the testing methodology, it is time to perform the test. In many aspects, the execution of a penetration test plan can be compared to the execution of a military campaign. In such a campaign, there are three distinct phases: reconnaissance, attack, and (optionally) occupation.

During the reconnaissance phase (often called the “discovery” phase), the tester will generally survey the “scene” of the test. If the tester is planning a physical penetration, the reconnaissance stage will consist of examining the proposed location for any weaknesses or vulnerabilities. The tester should look for any noticeable patterns in the way the site operates. Do people come and go at regular intervals? If there are guard services, how closely do they examine people entering and leaving the site? Do they make rounds of the premises after normal business hours, and are those rounds conducted at regular times? Are different areas of the site occupied at different times? Do people seem to all know one another, or do they seem to be strangers to each other. The goal of physical surveillance is to become as completely familiar with the target location as possible and to establish the repeatable patterns in the site’s behavior. Understanding those patterns and blending into them can be an important part of the test.

If an electronic test is being performed, the tester will use the reconnaissance phase to learn as much about the target environment as possible. This will involve a number of mapping and surveillance techniques. However, because the tester cannot physically observe the target location, electronic probing of the environment must be used. The tester will start by developing an electronic “map” of the target system or network. How is the network laid out? What are the main access points, and what type of equipment runs the network? Are the various hosts identi?able, and what operating systems or platforms are they running? What other networks connect to this one? Is dial-in service available to get into the network, and is dial-out service available to get outside?

Reconnaissance does not always have to take the form of direct surveillance of the subject’s environment. It can also be gathered in other ways that are more indirect. For example, some good places to learn about the subject are:

• Former or disgruntled employees

• Local computer shows

• Local computer club meetings

• Employee lists, organization structures

• Job application handouts and tours

• Vendors who deliver food and beverages to the site

All this information will assist the tester in determining the best type of attack(s) to use based on the platforms and services available. For each environment (physical or electronic), platform, or service found during the reconnaissance phase, there will be known attacks or exploits that the tester can use. There may also be new attacks that have not yet made it into public forums. The tester must rely on the experience gained in previous tests and the knowledge of current events in the ?eld of information security to keep abreast of possible avenues of attack.

The tester should determine (at least preliminarily) the basic methods of attack to use, the possible coun-termeasures that may be encountered, and the responses that may be used to those countermeasures.

The next step is the actual attack on the target environment. The attack will consist of exploiting the weaknesses found in the reconnaissance phase to gain entry to the site or system and to bypass any controls or restrictions that may be in place. If the tester has done a thorough job during the reconnaissance phase, the attack phase becomes much easier.

Timing during the attack phase can be critical. There may be times when the tester has the luxury of time to execute an attack, and this provides the greatest ?exibility to search, test, and adjust to the environment as it unfolds. However, in many cases, an abundance of time is not available. This may be the case if the tester is attempting to enter a building in between guard rounds, attempting to gather information from ?les during the owner’s lunch hour, or has tripped a known alarm and is attempting to complete the attack before the system’s intrusion response interval (the amount of time between the recognition of a penetration and the initiation of the response or countermeasure) is reached. The tester should have a good idea of how long a particular attack should take to perform and should have a reasonable expectation that it can be performed in the time available (barring any unexpected complications).

If, during an attack, the tester gains entry into a new computer or network, the tester may elect to move into the occupation phase of the attack. Occupation is the term used to indicate that the tester has established the target as a base of operations. This may be because the tester wants to spend more time on the target gathering information or monitoring the state of the target, or the tester may want to use the target as a base for launching attacks against other targets. The occupation phase presents perhaps the greatest danger to the tester, because the tester will be exposed to detection for the duration of the time he or she is resident in the target environment. If the tester chooses to enter the occupation phase, steps should be taken to make the tester’s presence undetectable to the greatest extent possible.

It is important to note that a typical penetration test may repeat the reconnaissance/attack/occupation cycle many times before the completion of the test. As each new attack is prepared and launched, the tester must react to the attack results and decide whether to move on to the next step of the test plan, or abandon the current attack and begin the reconnaissance for another type of attack. Through the repeated and methodical application of this cycle, the tester will eventually complete the test.

Each of the two basic test types — physical and electronic — has different tools and methodologies. Knowledge of the strengths and weaknesses of each type will be of tremendous help during the execution of the penetration test. For example, physical penetrations generally do not require an in-depth knowledge of technical information. While they may require some specialized technical experience (bypassing alarm systems, for example), physical penetrations require skills in the area of operations security, building and site operations, human nature, and social interaction.

The “tools” used during a physical penetration vary with each tester, but generally fall into two general areas: abuse of protection systems and abuse of social interaction. Examples of abuse of protection systems include walking past inattentive security guards, piggybacking (following someone through an access-con-trolled door), accessing a ?le room that is accidentally unlocked, falsifying an information request, or picking up and copying information left openly on desks. Protection systems are established to protect the target from typical and normal threats. Knowledge of the operational procedures of the target will enable the tester to develop possible test scenarios to test those operations in the face of both normal and abnormal threats.

Lack of security awareness on the part of the victim can play a large part in any successful physical penetration test. If people are unaware of the value of the information they possess, they are less likely to protect it properly. Lack of awareness of the policies and procedures for storing and handling sensitive information is abundant in many companies. The penetration tester can exploit this in order to gain access to information that should otherwise be unavailable.

Finally, social engineering is perhaps the ultimate tool for effective penetration testing. Social engineering exploits vulnerabilities in the physical and process controls, adds the element of “insider” assistance, and combines it with the lack of awareness on the part of the subject that they have actually contributed to the penetration. When done properly, social engineering can provide a formidable attack strategy.

Electronic penetrations, on the other hand, generally require more in-depth technical knowledge than do physical penetrations. In the case of many real-life attackers, this knowledge can be their own or “borrowed” from somebody else. In recent years, the technical abilities of many new attackers seem to have decreased, while the high availability of penetration and attack tools on the Internet, along with the sophistication of those tools, has increased. Thus, it has become relatively simple for someone without a great deal of technical knowledge to “borrow” the knowledge of the tool’s developer and in?ict considerable damage on a target. There are, however, still a large number of technically advanced attackers out there with the skill to launch a successful attack against a system.

The tools used in an electronic attack are generally those that provide automated analysis or attack features. For example, many freely available host and network security analysis tools provide the tester with an automated method for discovering a system’s vulnerabilities. These are vulnerabilities that the skilled tester may be able to ?nd manually, but the use of automated tools provides much greater ef?ciency. Likewise, tools like port scanners (that tell the tester what ports are in use on a target host), network “sniffers” (that record traf?c on a network for later analysis), and “war dialers” (that systematically dial phone numbers to discover accessible modems) provide the tester with a wealth of knowledge about weaknesses in the target system and possible avenues the tester should take to exploit those weaknesses.

When conducting electronic tests there are three basic areas to exploit: the operating system, the system con?guration, and the relationship the system has to other systems. Attacks against the operating system exploit bugs or holes in the platform that have not yet been patched by the administrator or the manufacturer of the platform. Attacks against the system con?guration seek to exploit the natural tendency of overworked admin-istrators not to keep up with the latest system releases and to overlook such routine tasks as checking system logs, eliminating unused accounts, or improper con?guration of system elements. Finally, the tester can exploit the relationship a system has with respect other systems to which it connects. Does it have a trust relationship with a target system? Can the tester establish administrative rights on the target machine through another machine? In many cases, a successful penetration test will result not from directly attacking the target machine, but from ?rst successfully attacking systems that have some sort of “relationship” to the target machine.

Reporting Results

The ?nal step in a penetration test is to report the ?ndings of the test to management. The overall purpose and tone of the report should actually be set at the beginning of the engagement with management’s statement of their expectation of the test process and outcome. In effect, what the tester is asked to look for will determine, in part, the report that is produced. If the tester is asked to examine a company’s overall physical security, the report will re?ect a broad overview of the various security measures the company uses at its locations. If the tester is asked to evaluate the controls surrounding a particular computer system, the report will most likely contain a detailed analysis of that machine.

The report produced as a result of a penetration test contains extremely sensitive information about the vulnerabilities the subject has and the exact attacks that can be used to exploit those vulnerabilities. The penetration tester should take great care to ensure that the report is only distributed to those within the management of the target who have a need-to-know. The report should be marked with the company’s highest sensitivity label. In the case of particularly sensitive or classi?ed information, there may be several versions of the report, with each version containing only information about a particular functional area.

The ?nal report should provide management with a replay of the test engagement in documented form. Everything that happened during the test should be documented. This provides management with a list of the vulnerabilities of the target and allows them to assess the methods used to protect against future attacks.

First, the initial goals of the test should be documented. This will assist anyone who was not part of the original decision-making process in becoming familiar with the purpose and intent of the testing exercise. Next, the methodology used during the test should be described. This will include information about the types of attacks used, the success or failure of those attacks, and the level of dif?culty and resistance the tester experienced during the test. While providing too much technical detail about the precise methods used may be overly revealing and (in some cases) dangerous, the general methods and procedures used by the testing team should be included in the report. This can be an important tool for management to get a sense of how easy or dif?cult it was for the testing team to penetrate the system. If countermeasures are to be put in place, they will need to be measured for cost-effectiveness against the value of the target and the vulnerabilities found by the tester. If the test revealed that a successful attack would cost the attacker U.S.$10 million, the company might not feel the need for additional security in that area. However, if the methodology and procedures show that an attack can be launched from the Internet for the price of a home computer and an Internet connection, the company might want to put more resources into securing the target.

The ?nal report should also list the information found during the test. This should include information about what was found, where it was found, how it was found, and the dif?culty the tester had in ?nding it. This information is important to give management a sense of the depth and breadth of the security problems uncovered by the test. If the list of items found is only one or two items long, it might not trigger a large response (unless, of course, the test was only looking for those one or two items). However, if the list is several pages long, it might spur management into making dramatic improvements in the company’s security policies and procedures.

The report should give an overall summary of the security of the target in comparison with some known quantity for analysis. For example, the test might ?nd that 10 percent of the passwords on the subject’s computers were easily guessed. However, previous research or the tester’s own experience might show that the average computer on the Internet or other clients contains 30 percent easily guessed passwords. Thus, the company is actually doing better than the industry norm. However, if the report shows that 25 percent of the guards in the company’s buildings did not check for employee badges during the test, that would most likely be considered high and be cause for further action.

The report should also compare the initial goals of the test to the ?nal result. Did the test satisfy the requirements set forth by management? Were the results expected or unexpected, and to what degree? Did the test reveal problems in the targeted area, or were problems found in other unrelated areas? Was the cost or complexity of the tests in alignment with the original expectations of management?

Finally, the report should also contain recommendations for improvement of the subject’s security. The recommendations should be based on the ?ndings of the penetration test and include not only the areas covered by the test, but also ancillary areas that might help improve the security of the tested areas. For example, inconsistent system con?guration might indicate a need for a more stringent change control process. A successful social engineering attempt that allowed the tester to obtain a password from the company’s help desk might lead to better user authentication requirements.

Conclusion

Although it seems to parallel the activities of real attackers, penetration testing, in fact, serves to alert the owners of computers and networks to the real dangers present in their systems. Other risk analysis activities, such as automated port scanning, war dialing, and audit log reviews, tend to point out the theoretical vulner-abilities that might exist in a system. The owner of a computer will look at the output from one of these activities and see a list of holes and weak spots in a system without getting a good sense of the actual threat these holes represent. An effective penetration test, however, will show that same system owner the actual damage that can occur if those holes are not addressed. It brings to the forefront the techniques that can be used to gain access to a system or site and makes clear the areas that need further attention. By applying the proper penetration testing techniques (in addition to the standard risk analysis and mitigation strategies), the security professional can provide a complete security picture of the subject’s enterprise.

Tags: Information Security, Information System Audit

Posted in Information System Audit | No Comments »