March 1993 Computer Audit Update

interesting academic exercise. A security profile will increasingly reflect a generic demand both in the public and private sectors. Integrated, multi-enterprise solutions will dictate a common level of trust in information systems between the various parties. Such a need may be just an 'entry ticket' to a closed group of enterprises (a financial or administrative service) or may be driven by national or even pan-national legislation or regulation (Data Protection).

A simple yet flexible profile with associated policies, procedures and codes of good practice will be easier to agree and implement than unique, enterprise oriented processes. The vendor will only develop products and services if there is a defined and measurable user demand. But in any business decision there is an element of risk; vendors are already preparing to define product solutions against generic profiles (both functionality and assurance) even without a final marketplace position. Security criteria like other major IT standards, are at the heart of this dichotomy.

There is a need for generic profiles in the audit world. The FC Accountabil i ty Policy demands that there be ex tens ive audi t components to ensure that user interactions are recorded and attributed to the accountable user identify. These are obvious in a single computer environment under a multiuser operating system, it needs substantial control however in a distributed multi-management system, where universal identification and the associated event controls are under different management jurisdictions!

The accounting and auditing community must be in the forefront of the debate. Their voices must be heard. One thing is certain as society becomes more dependent upon IT, so the quality of the services infrastructure including information security will become more important. The Federal Criteria illustrates an acceptance by the US National Authorities that the Information Systems secur i ty problem must be more adequately addressed by the Commercial sector.

IT SECURITY TESTING, A P R A C T I C A L GUIDE - - PART 5

SECURITY STRESS/LOADING TESTING

Bernard Robertson and David Pullen PA Consulting Group

Stress/loading testing is a fairly common activity in software and hardware functional testing. The objective of stress/loading testing is to determine if the software or hardware under test meets its performance requirements. Security stress/loading testing uses the same techniques as functional stress/loading testing but the objective of the testing is: to determine if the component under test develops any security weakness as it reaches and exceeds its performance limits.

The performance of a component may be tested in terms of throughput (e.g. the number of Iogons per second that a system can deal with) or in terms of total capacity (e.g. the total number of users that may be logged on to the system at any one time).

Test areas

Experience indicates that stress/loading testing is particularly applicable to systems which are:

• Already running close to capacity.

• Highly visible (e.g. real-time client activated systems).

• Widely varying in utilization (e.g. an ATM system).

• Safety or mission critical (e.g. flight control systems).

@1993 Elsevier Science Publishers Ltd 7

Computer Audit Update March 1993

At risk because the level of utilization could easily be affected by external influences (e.g. a share dealing system).

Stress/loading testing may be carried out on different components within a selected system for a variety of performance parameters.

Components

Components which may be of particular interest to security testers are:

Communications lines, particularly those be- tween core network nodes which carry large volumes of data.

• Cryptographic devices.

• Output devices (e.g. printers).

• Communications interface modules.

Parameters

Parameters which may be of particular interest to security testers are:

• The number of messages or transactions per time period.

• The number of concurrent system users.

• The number of transactions involving heavy processing loads.

• The processing profile (e.g. 90% of the trans- actions in 10% of the day).

Test process

Stress/ loading test ing would be t ime consuming if all the components of a system were tested individually. It is therefore essential to take a structured approach to the testing to ensure that it is carried out effectively and efficiently. The security testing process should adhere to the

general structure described in the second article in this series. Stress/loading testing consists of 7 phases which are detailed below.

Identification of potential bottlenecks

Once an understanding of the operation of the system has been obtained, a combination of paper analysis and brainstorming techniques should be used to identify potential bottlenecks. These bottlenecks could result in problems when the system is fully loaded.

Analysis of identified bottlenecks

The bottlenecks identified above should be analysed in more detail to determine if they are likely to cause any security problems. The analysis should involve reviewing the areas that would be affected by the bottlenecks and identifying the possible effects of overloading (including consequential effects).

Identification of test areas

The two phases above lead to the identification of areas to be tested. It is important at this stage not to leave out any areas which could lead to security failures when the system is loaded up to, and beyond, capacity. The testers should therefore act conservatively when eliminating test areas.

Identification of test limits

Before any testing is undertaken the tester should identify the specified performance limits of the components to be tested and the level to which the components should be stressed/loaded during testing. For example, a communications controller should have a performance specif icat ion indicat ing the maximum expected throughput and a transaction processing appl icat ion should have the transaction performance documented in the requirements specifications. This information will be needed when specifying the performance requirements of the test tools to be used and for identifying the volumes and types of data required for the tests.

8 ©1993 Elsevier Science Publishers Ltd

March 1993 Computer Audit Update

Identification of test tools

In most cases it will be necessary to develop test tools for stress/loading tests. These tools may have been developed as part of functional testing and should be used wherever possible. Further information about test tools may be found in a later article in this series: 'Specification and Use of Security Test Tools'. Problems of which the tester should be aware when identifying test tools for stress/loading testing are:

Component drivers should not use the same processors as the component being driven because peculiarities in behaviour at perfor- mance limits may be masked as a result of the similar characteristics of the two compo- nents.

Transactions should not be monitored in real- time by the component driver as it will affect the performance measurements. If transac- tions must be monitored in real-time, then the monitoring should be undertaken by a separ- ate component which does not affect the transaction rates.

~s~g

When performing stress/loading testing the tester should always attempt to measure the responses of the system at levels just below, equal to, and just above the performance limit whilst continually recording or monitoring the system response.

Test analysis

An important part of stress/loading testing is the analysis of the test results. A technique which generally proves to be useful, and which is recommended, is the plotting of graphs of performance characteristics as transaction rates or data loads are increased up to, and beyond, the performance limits. For example, graphs of:

• Throughput against the delay time between transactions.

Response time against the volume of data in a database as it is increased up to, and be- yond, the maximum level specified.

Examples of tests

There are many areas which could be subjected to st ress/ loading testing, some examples are described below.

Simultaneous Iogons

Test that all passwords are checked when a large number of users Iogon after the system is returned to service following a system outage. The test could be achieved by setting up a large number of in te r face s imu la to r s wi th pre-programmed Iogon sequences containing invalid passwords timed to Iogon at the time the service is restored.

Response of cryptographic processes

Test that all the cryptographic processes are performed correctly as they are loaded to maximum capacity. For example, the tester could attempt to drive a communications link encryptor beyond its maximum load and monitor the output to ensure that the data was still being correctly encrypted.

Audit log

Test the response of the system to filling up the disk space allocated to an audit log. In pa r t i cu la r what happens to reco rds of transactions after the log is full. This test could be carried out by adding data to the audit log until it is nearly full and then initiating a sequence of transactions sufficient to exceed the capacity of the log file whilst monitoring the response of the system. At the end of the test the log file should be checked to ensure that no records have been lost.

User records

Test the response of the system to maximum number of user records in the access control system being exceeded. This test could be

@1993 Elsevier Science Publishers Ltd 9

Computer Audit Update March 1993

carried out by adding user records to the user file until the maximum number of records is approached by either creating new users via the access control system or adding them directly to the file. New users could then be added via the access control system to take the number of records up to, and past, the maximum whilst monitoring the response of the system.

Integrity of communications module

The integrity of a communications module may be tested as it is run up to, and beyond, its performance capacity. For example, the tester may attempt to increase the throughput of a communications module whilst monitoring the ability of the module to maintain the integrity of the data when dealing with communications errors.

Process intensive transaction mix

Many systems have a small number of transactions which require intensive processing. Under normal operation these transactions may only constitute a small percentage of the overall processing requirement. However there may be occasions when a change in circumstances will result in a large increase in the percentage of process intensive transactions. For example changes in airline bookings during adverse weather conditions. This could be tested by driving the system with terminal simulators loaded with a large number of bookings changes.

I s s u e s

There are a number of issues which the tester will need to keep in mind when developing and reporting on the tests, in particular it is important to ensure that:

The test system is an exact copy of the live system otherwise the results may not be re- alistic.

There is a reasonable likelihood of the test stress/load levels actually occurring on the target system.

The results of the testing are fully analysed and understood, and options for resolving the problems carefully considered. For example, if a system fails when 100 users Iogon, then there are at least three possible solutions to the problem:

the system capacity may be expanded by making modifications to the hardware or software;

- - a second system may be purchased and the two systems run in parallel;

the system limitations may be accepted and the number of concurrent Iogons limited to 99.

The next article in this series outlines the u s e

of failure mode testing as part of a security testing programme.

Bernard Robertson is a principal consultant in the Security Consulting Practice of PA Consulting Group. He has extensive experience in performing a range of security testing programmes for public and financial sector clients. Bernard is a regular speaker on IT security issues and holds degrees in Economics and Business Administration. David Pullen is a senior consultant within the same Security Consulting Practice. Over the last five years he has conducted several security testing projects, including one lasting two years with a team of 15 security testers. David is a Physics graduate and a qualified teacher who has produced a wide range of educational material on security testing.

DATA DOWNLOADING TECHNIQUES

Nicholas Higgins

Data Downloading is a subject of interest to many different areas of business. One area where it is becoming increasingly important is

10 ©1993 Elsevier Science Publishers Ltd