It security testing, a practical guide — Part 1

4
November 1992 Computer Audit Update Does the package come with adequate do- cumentation? Is the package, and any package amend- ments, thoroughly tested before it is put live? Is the auditor able to run CAATs against the package data files if he decides to adopt this approach as part of his regular audits of the system. This can be particularly difficult if file layouts or database structures are not made available as part of the package documenta- tion. Alternatively is there a report writer pro- gram available with the package which can be used by the auditor? If the package can be extensively tailored by the input of parameters, are these parameters adequately controlled? Many packages are provided with a list of parameter options which can be used to tailor the processing to meet the needs of individual organizations. Some of these options can be used to signifi- cantly amend processing, including switching off control options. Sensitive parameters must be closely controlled. I.J. Douglas is deputy head of the Systems Audit Section of Barclays Bank. The views expressed in this article are personal, and not necessarily those of his employer. IT SECURITY TESTING, A PRACTICAL GUIDE --- PART 1 Bernard Robertson and David Pu/len PA Consulting Group About this series Whenever an IT system has requirements for a high level of confidentiality, integrity or availability it is essential that the functions of the system, and supporting processes and procedures, are thoroughly tested. The detailed testing programme should therefore include functional system testing and security testing where the focus is on the delivery of security functionality supporting the requirements for confidentiality, integrity and availability. Wherever possible, and appropriate, IT security testing should be incorporated in the system development process since changes arising from problems found in the security test phase will be cheaper to implement the earlier they are detected. Security testing can be complex and challenging and also expensive if it is not correctly controlled. The success of a security testing programme is therefore dependent upon the experience of the test team. This is the first in a series of nine articles on IT security testing that will provide practical advice to people embarking on security testing programmes. The first two articles describe the: Objectives of, and preparation for, security testing. Documentation and process for successful security testing. The remaining seven articles will cover specialized techniques and topics that will give the security tester the depth of understanding required for success. These articles will cover: Hardware and software security testing. Security testing of communications channels. Stress/loading testing. Failure mode testing. Specification, development and use of se- curity test tools. System scoring techniques. Follow up after testing for system improve- ment. ©1992 Elsevier Science Publishers Ltd 7

Transcript of It security testing, a practical guide — Part 1

Page 1: It security testing, a practical guide — Part 1

November 1992 Computer Audit Update

• Does the package come with adequate do- cumentation?

• Is the package, and any package amend- ments, thoroughly tested before it is put live?

Is the auditor able to run CAATs against the package data files if he decides to adopt this approach as part of his regular audits of the system. This can be particularly difficult if file layouts or database structures are not made available as part of the package documenta- tion. Alternatively is there a report writer pro- gram available with the package which can be used by the auditor?

If the package can be extensively tailored by the input of parameters, are these parameters adequately controlled? Many packages are provided with a list of parameter options which can be used to tailor the processing to meet the needs of individual organizations. Some of these options can be used to signifi- cantly amend processing, including switching off control options. Sensitive parameters must be closely controlled.

I.J. Douglas is deputy head of the Systems Audit Section of Barclays Bank. The views expressed in this article are personal, and not necessarily those of his employer.

IT SECURITY TESTING, A PRACTICAL GUIDE --- PART 1

Bernard Robertson and David Pu/len PA Consulting Group

About this series

Whenever an IT system has requirements for a high level of confidentiality, integrity or availability it is essential that the functions of the system, and suppor t ing processes and procedures, are thoroughly tested. The detailed

testing programme should therefore include functional system testing and security testing where the focus is on the delivery of security functionality supporting the requirements for confidentiality, integrity and availability.

Wherever possible, and appropriate, IT security testing should be incorporated in the system development process since changes arising from problems found in the security test phase will be cheaper to implement the earlier they are detected. Security testing can be complex and challenging and also expensive if it is not correctly controlled. The success of a securi ty test ing programme is therefore dependent upon the experience of the test team.

This is the first in a series of nine articles on IT security testing that will provide practical advice to people embarking on security testing programmes. The first two articles describe the:

• Objectives of, and preparation for, security testing.

• Documentation and process for successful security testing.

The remaining seven articles will cover specialized techniques and topics that will give the security tester the depth of understanding required for success. These articles will cover:

• Hardware and software security testing.

• Security testing of communications channels.

• Stress/loading testing.

• Failure mode testing.

• Specification, development and use of se- curity test tools.

• System scoring techniques.

• Follow up after testing for system improve- ment.

©1992 Elsevier Science Publishers Ltd 7

Page 2: It security testing, a practical guide — Part 1

Computer Audit Update November 1992

OBJECTIVES AND PREPARATION FOR TESTING

Introduction

The normal IT system development process broadly consists of five phases:

• Determining the use requirements.

• Producing functional, design and testing spe- cifications,

• Unit development orcoding.

• Testing.

• User acceptance and sign-off.

There are two overall aims of the testing phase: to gain sufficient confidence that the system concerned correctly carries out the intended functions (positive testing); and to gain sufficient confidence that the system concerned does not do anything which it should not (negative testing). The first of these aims is fairly easy to specify and to conduct in a rigorous fashion. The second, however, is far more difficult to specify from the outset and in theory is an infinite task.

Non-security functional testing of any component or system is primarily concerned with positive testing. Any negative testing usually occurs as a by-product of the positive testing and its extent depends very much on the experience of the testing staff and their understanding of the system.

Where there is a requirement for a high level of availability, confidentiality or integrity, security testing may be appropriate. Security testing has an entirely different emphasis from functional testing as there is a much greater amount of negative testing required due to the need to gain sufficient confidence in the system under test. The positive testing can be restricted to proving that the specified security requirements of the

system and its components are present and operate correctly. With negative security testing it is much more difficult: to specify the tests; to define acceptance criteria; and to obtain a measure of test quality. This difficulty stems from the basic constraints that no security can be perfect-- one can only achieve a certain level of security.

Objectives

There are two key objectives to be achieved in security testing. These are that:

Positive testing will ensure that the design is implemented as specified in the required do- cumentation.

Negative testing will seek to identify any un- foreseen weaknesses in the design or im- plementation.

These posit ive and negat ive test ing objectives are the main elements of the security testing process but there are some other aspects which need to be considered. These are:

• To identify any areas of excessive inconveni- ence attributable to security measures.

That the security testing should also evaluate and refine all security related procedures which form part of the overall system.

That the knowledge of any security weak- nesses should be restricted to a minimum number of individuals because a number of the weaknesses may prove too difficult, costly or time consuming to solve and the decision may be taken to accept the risk in some cases.

Preparation for security testing

Before embarking on a security testing programme there are certain organizational issues which need to be considered and addressed.

8 ©1992 Elsevier Science Publishers Ltd

Page 3: It security testing, a practical guide — Part 1

November 1992 Computer Audit Update

Legal issues

In the light of the recent Computer Misuse Act 1990 in the UK and similar legislation in place or planned in other countries, anyone considering performing security testing on a system should ensure that they obtain written permission from the system management. Such permission should clearly state the authorization rights granted to the testers and the time period for which such rights are valid. Failure to obtain such authority could, in certain circumstances, leave the tester open to prosecution.

Management backing

As well as the legal requirement to gain management authority to perform security testing, it is important that management are informed and suppor t ive of the test ing programme. Management who have security testing forced upon them are unlikely to be cooperative in granting access to personnel, machine time, etc. This can result in testing being curtailed or abandoned. The managers of the system to be tested should be consulted at the earliest possible opportunity and kept aware of the progress of the testing. Distribution of the test specification and an informal feedback session at the end of the testing phase contribute towards achieving this objective. A copy of the final test report should be given to the management of the system being tested.

Selection of testing facilities

Security testing should ideally be performed by running the target system on a processor that is not connected to the production system. It is often possible to use a development machine for testing purposes. There are a number of reasons for this recommendation:

• It prevents potential corruption of live data.

• There is no risk of commercial loss due to the unintentional failure of the live system.

• Any test tools that may be used by the testers are not accessible (knowingly or unknow- ingly) to live users.

Timing

The best time to perform security testing is when the planned application and security functionality has already been thoroughly tested by the system development test team and before the system goes into live production. This allows deficiencies to be identified in a development environment where they may be cost-effectively corrected whilst, more importantly, preserving the security of the live environment.

Test team

For maximum effectiveness the security test team should compr ise exper ienced so f twa re /ha rdware tes ters wi th a good understanding of the business and security risks that the target system faces. Staff who have been involved in the system's development should not be included in the team since they usually lack the necessary objectivity to identify security problems.

Confidentiality

The weaknesses and breaches discovered during testing could be a useful source of information to anyone who wishes to attack or manipulate the system for their own purposes. For this reason the results of the tests and the final report should be distributed on a 'need to know' basis.

Test planning

Testing is a resource intensive activity. It is important that the planning is thorough, and includes:

The physical and human resources required.

The timescale for the programme - - which will often be constricted bythe late completion of development and pressures for live oper- ation to begin. Timescales must be reason- able and the test team should be committed to them.

©1992 Elsevier Science Publishers Ltd 9

Page 4: It security testing, a practical guide — Part 1

Computer Audit Update November 1992

• The priorities for the testing.

• The allocation of time to the correction of any weaknesses identified during testing.

Assuming the areas described above are properly addressed, the tester will be well positioned to begin the test programme. The next article in this series will describe the process of security testing and the documentation required for it to be performed properly.

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 has produced security testing educational material

DO YOU HAVE ENOUGH INFORMATION TO DO YOUR JOB?

Deb Salisbury Touche Ross Management Consultants

A recent information management survey revealed that almost 40% of the respondents did not have sufficient information to do their jobs effectively. The survey, conducted by Touche Ross Management Consultants, also showed that this is a more significant problem in larger organizations, and that regardless of the size of the company more people say they have too little information than say they have too much. The

problems of too little of the right information and too much of the wrong information arise from a lack of understanding of the principles of good information management.

The survey revealed that management has become more focused on the technological means of information management (IM) rather than the business implications of IM and that there is a lack of perception of the wider business impacts relating to the handling of information and therefore ignorance of the benefits of good IM. This article aims to explain the principles and advantages of good I M and to reveal how today's organizations manage their information and how they think they will manage it in the future. Statistics from the survey will be used to illustrate both good and bad examples of information management. The concept of an IM strategy, the use of different storage media and methods of communication will be examined before a conclusion is drawn about IM today and in the future.

Information management

So what is IM? For the purposes of the survey, IM was defined as: 'the effective production, storage, retrieval and dissemination of information in any form', to achieve the business goals of the organization. Only 24% of the respondents thought that IM included all these aspects.

Paper is currently the predominant form of information storage and will continue to have a role to play as an information medium. Therefore to manage information effectively a good deal of attention needs to be directed towards the management of paper-based information. However, management persist in giving this aspect of IM a low priority. The consequences of poor IM range from inability to find information and reworking exercises, through accidental loss of information (e.g. as a result of fire or water damage), to penalties and litigation.

The survey gathered views on the understanding of IM, the trends in its application

10 ©1992 Elsevier Science Publishers Ltd