The security phase of software development

Computer Fraud & Security Bulletin July 1992

Conclusion

The increased movement away from the mainframe and its inherent data security to the

network allows users to be individually more

productive and yet, as this move takes place, the value of the data on the network is increasing.

Currently the security of data on networks or PC based environments is inadequate and there

are a number of ways to ensure that security is

given. This means looking at all areas of the corporate PC computing environment, from the

hardware that is being used, software utility

solutions available to ensure adequate data

security and integrity, staff training and correct access rights. The move to Workgroup computing will take place on most applications and

information can be secured and maintained with

the correct implementation of company wide data integrity solutions.

TESTING SECURE SYSTEMS

The security phase of software development

Befnafd ~obe~son, PA ~o~s~~t~~~, UK

Software development ~picaily consists of

determining user requirements, developing

functional, design and testing specifications,

coding, testing and user acceptance. For those systems where confidentiality, integrity or

availability are user requirements, a specific

security testing phase will be required. Such a phase will have the objective of ensuring that intended security features function correctly without security weaknesses.

The scope of security testing

There are two aims of any security testing programme:

- to gain sufficient confidence that the system correctly fulfils its specification (positive

testing),

- to gain sufficient confidence that the system concerned does not do anything which it

should not (negative testing).

The positive testing can be restricted to proving that the specified security requirements

of the system and its components are present and operate correctly. The scope of negative testing

is much more difficult to define due to the fact that

no security can be perfect. This leads to a central

difficulty of security testing -defining what level of security is adequate.

It is with these constraints in mind that the

objectives of a security testing programme should

be prepared before security testing begins.

An example set of security testing objectives

There are several objectives for security testing.

- Positive Testing. Positive security testing

ensures that the design, includjng security

requirements, are implemented as specified in the requirements documentation and that standards are adhered to.

- Negative Testing. Negative security testing

seeks to identify unforeseen weaknesses in

the design or implementation. The testing should also seek to find any unwanted

features which have been introduced

intentionally or unintentionally into the

system.

A security testing programme should additionalty include:

- the identification of any areas of excessive inconvenience attributable to security measures. Such features often become a

target for people to find a ‘better’ way, resulting in a level of security that is worse

than having no measures at all

12 01992 Elsevier Science Publishers Ltd

July 1992 Computer Fraud & Security Bulletin

- the evaluation and refinement of all security

related procedures which form part of the

overall system

- limiting knowledge of any security weaknesses to a minimum.

Testing process

The testing process may be shortened by

omitting certain phases but the consequence of doing so is a loss of thoroughness. There are

seven phases in the process.

(1) System familiarization. Members of the

test team must familiarize themselves with system documentation in order to understand the business objectives and functions of the system. This activity enables the testers to ascertain the

existence, currency and quality of systems documentation, the standards of which should be commented upon in the final report. The security testers should be denied access to confidential

systems documentation, such as encryption key

values, in order to maintain a degree of reality in the testing.

(2) Business and security control

identification. An inventory of the business and

security control features is compiled from the

documentation and is a key reference in risk ident~fjcatjon. Such features may include Iogical access systems, audit trails, the use of encryption

and authentication, file duplication and provision

of audit trails.

(3) Risk identification. The objective risk

identification phase is the production of a list of

areas to be tested which may then be prioritized:

- to focus testing on those ares where the

exposures are considered greatest

- to make the best use of the testing resources available.

(4) Selection of appropriate testing techniques. Testing techniques are then selected by considering:

- the maturity of the system.

(5) Specified (structured) tests. A specification is then written which details all of the

information gathered in the previous four phases, specifies the areas of the system to be tested

and, in general terms, the tests to be performed. From this specification, test scripts are developed

which describe the tests in detail for each testing

area. These tests are then carried out.

(6) Attack tests. From the results of the

specified structured tests, a list of possible attacks is then developed. The attacks are

designed to take advantage of any weaknesses identified in the previously specified structured

testing. All of the attacks are then performed. If an attack fails to succeed as originally designed,

it may be modified and retested. All stages of the test and its results are documented.

(7) Problem classification and reporting. The

last phase in the testing process is to classify all

discovered problems, make appropriate recommendations for improvement and produce

a test report.

Types of security testing

Of the many techniques available the most

widely used techniques are:

Functiona/ tests {positive). Tests are

conducted to provide confirmation of the correct

fun~ioning of the security features of a system.

This testing is performed by preparing and running a number of test scripts which detail in a

step-by-step fashion actions and expected

results.

Functional tests (negative). Tests are conducted to uncover any security weaknesses or system errors which create security problems.

Test scripts are also prepared for this technique.

Error insertion Tests. A variety of errors are

injected into data at likely points in the system and

checks are made to ensure that no security breaches arise or security weaknesses are

detected. - the type of system tested

01992 Elsevier Science Publishers Ltd 13


Failure Simulations Tests. Simulated failures are deliberately introduced at appropriate points

in the system and checks are then made to ensure that no security breaches or weakness

result.

Stress/Loading Tests. Systems are loaded to

maximum capacity and tests are conducted to

ensure that the security requirements are upheld. The tests are conducted at just below and just

above the critical thresholds and the

effectiveness of the security controls checked.

Attack Tests. Attack testing differs from the

above techniques in one vital facet. It may use some of the previously described testing techniques but in terms of its organization, it is

much less structured and more experience

based. It may be said that a good attack tester requires the mentality of a determined hacker. The use of attack testing techniques can be expensive in terms of the tester’s requirement for

system familiarization, test planning and execution. However, this must be weighed

against the risks of undetected security

weaknesses remaining in the system during live

operation.

Preparation for security testing

In the tight of the Computer Misuse Act 1990 in the UK and similar legislation in place or

planned in other countries, anyone considering attack testing should ensure that he or she

obtains written permission from the system

management. It should clearly state the

authorization rights granted to the testers and the time for which such rights have been granted.

Failure to obtain such authority could leave the

tester open to prosecution.

It is important that management are informed

and support testing.’ 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. Distribution of the test specification and an informal feedback session, at the end of the specified structured testing

phase, are useful methods of keeping

management informed.

14

Selection of testing facilities. It is advisable

for security testing to be performed 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:

-

-

-

potential corruption of live data is prevented

the risk of commercial loss due to the

unintentional failure of the live system is removed

test tools are rendered inaccessible to live

users.

Timing. Security testing is best performed

just before the system goes into live production. This allows deficiencies to be identified in a

development environment where they may be

more cost-effectively corrected and, more importantly, preserve the security of live production.

Test Team. The security test team should

comprise experienced software testers with a good understanding of the business and security

risks that the target system faces. Software engineers previously involved with the system’s development are not recommended for inclusion in the team because they lack the objectivity required.

Documentation

The impact and effectiveness of security

testing is highest when all of the steps involved

in it are clearly documented. There are at least three reasons for this:

- management can understand and approve the work involved

- system management and development staff

can understand the work that has been performed and its consequences

- system testers can easily recreate problems that have been discovered.

The scale of the documentation must be

01992 Elsevier Science Publishers Ltd


tailored to the size of the system under test. For

example if resources to be used are in the region

of 3-l 2 man months the following documentation should be prepared:

Security test strategy. This document

describes the overall objectives of the testing,

identifies the resources required, defines the

objectives of the testing and describes how the testing will fit within the overall testing objectives.

with regard to the risks identified at the

specification stage. This report allows

management to make an early decision about what action and resources are likely to be

required.

Test specification. This should be prepared

after the team has familiarized itself with the

system, it should describe the rationale behind

the testing, the risks identified within the system

and the various subgroups of test that will be

performed, e.g. financial limit tests, logical access control tests and tests on the accuracy of

the audit trail. In addition this document should describe the procedures for problem reporting, the test environment and configuration

requirements and what test data will be required.

-

-

-

-

Test scripts. These should be written at as low a level as possible so that a low skilled tester

can perform them without reference to the author.

They should describe exactly what the tester

shouid do and describe the expected result of each step. writing test scripts is the most difficult

and time consuming part of the process. Good

test results can only be achieved after thorough

scripts have been produced.

-

-

-

Test fogs. The testing begins when the test scripts have been completed. The tester should

maintain a log of each step of the script and

record exactly the results. These are vital in order -

to recreate errors or security problems.

Problem reports and logs. As testing proceeds problems will be identified. These

should be recorded immediately in a problem log with all relevant information that will allow the

system developer to recreate and subsequently fix the problem.

Examples of attacks

The key factors in effective attack development are a sound IT background,

knowledge of the target system and a ‘hacker’ mentality. Some forms of attack which may be

considered are:

Final report. This report completes the

documentation set and should be written at the

end of the testing cycle. The following items should be included:

a management summary briefly describing

the findings, results, conclusions and major

recommendations of the testing activity

a description of the test process

a description of the exact test configuration used

major findings of the testing phase. This

section should describe the results of running each test script

a classification system which categorizes the severity of the various problems found

a conclusion detailing the overall

assessment of the security of the system

against the agreed risks defined in the test

specification

recommendations to provide system developers with ideas about the causes of each of the problems

appendices should show the problem classification used and full details (extracted from the problem log) of all problems found.

Report overview. At the end of all testing it is

very useful to produce a short report detailing the problems found with a cross reference to the problem log. It should give an early assessment

to management of the severity of the problems

A terminate and stay resident (TSR) program. A TSR program could allow invisible activities to take place every time a particular

01992 Elsevier Science Publishers Ltd 15


application is run. For example, a banking application accessed by PC-based terminals

could be subverted by a TSR. The TSR would send its own commands from an otherwise

legitimate terminal address; these commands would be invisible to the terminal user. It could

transfer funds fraudulently. The best defence against this kind of attack is for the application

program to inhibit the TSR by removing all unrequired applications from primary storage as

its first activity. In a PC environment this could be

done by using a memory mapping utility.

Hidden trapdoors. System designers frequently make extensive system facilities

available to service engineers. Access to these

facilities is often based on a ‘hidden trapdoor’. Attack testers should always try to locate and enter these trapdoors and then examine the

range of facilities available.

Use of a data analyser to monitor the

network. If the system being tested involves the use of a communications network, a data

analyser should be connected to it and the traffic

using the network examined. Unless all network

traffic is encrypted, sensitive data is invariably visible. In some cases it is possible to capture

messages as they flow across the network,

modify and release them. The messages are then

sent on to their destination containing the modified data, without the communications protocol being aware of the modification.

Reset the inva~jd password count. Many

systems have an access control feature by which user-ids are suspended after a number of a failed

password attempts. Unfo~unately many of these

same systems keep the count of failed password

attempts in a very accessible file. Using available

system tools its is easy to edit or delete this file.

Editing it would allow an attacker to continue trying passwords until successful. Deleting the file could result in the system hanging when an invalid password is entered thus causing system

denial. Such an invalid password count should be stored in encrypted form. Alternatively storage in a hidden part of the application files may be considered.

Where is the password encryption source

code stored? Obtaining access to this code

frequently gives an attack tester information about the encryption algorithm used and also access to the encryption key; since this is almost

always stored within the source code. Although

access to a live system is usually well controlled, the encryption source code is often stored in the development area with the minimum of security.

What special privileges are available to the

system manager? One well-known mainframe

access package allows the system manager to read all users’ passwords. There is never a need

for this function. If a user forgets a password, the

password details should always be deleted and recreated from scratch. The potential security breaches caused by this unnecessary function are of intense interest to an attack tester.

Attempting to access the operating system by exiting the application abnormally. Most

security applications try and prevent users accessing operating system functions. However, in a number of cases we have found it relatively

easy to cause the application to terminate

abnormally and return the user to the operating system. Once in the operating system, system files, password files and system trace tools

become available. Sometimes the application

can be terminated by simply entering a strange combination of keystrokes.

Where are copies of the software stored? If

they are not stored securely, an attacker could

modify magnetic copies of source code to provide illegal functionality. Alternatively, an attacker

could examine paper copies of source code in order to identify weaknesses in an application

thus making the attack easier to accomplish. On

the matter of availability, testers should always

examine the period of time required to restore the

entire system from backups, A system that is critical to business survival but which cannot be used at short notice after a disaster cannot be

said to be very secure.

financial limits and checks. Many systems that are responsible for funds transfers are

subject to system enforced limits and checks.

16 01992 Elsevier Science Publishers Ltd


Testing should always try to find ways of

overcoming limits or avoiding checks. As an

example, in a system which pays customer accounts, a simple test is to enter a value that

overflows a fund’s field. If the overflow amount would normally be subject to management

checks but the amount actually displayed in the field is under such a limit, what amount is paid

and is the management check still enforced?

Protection of sensitive information. Some

business information, e.g. customer accounts

data or tenders to prospective clients, is confidential. Testing should try to access any

such records in the guise of users who would not

normally be able to view this type of data.

Conclusions

Security testing is a valuable, efficient and

necessary process in the development of secure IT systems. It can provide guidelines towards improved systems design and, if performed prior to live operation, proves the point that prevention

is better than cure.

Security testing should not be performed

without the full backing and involvement of both

senior management and the managers of the

system being tested. If possible everyone

associated with the testing should become

involved as early as possible and be keen to see

the results.

A good security tester is one with a sound IT background and some knowledge of the

business functionality of the system to be tested,

The ideal person will have the mentality of a

hacker. People who have been involved in specifying system functional testing, should

generally not be used for security testing because

they will lack objectivity.

Security testing can only be performed on a system that is fairly static. The best time to

perform such testing is after functional testing has

been completed but before the system goes into live production.

Security testing relies heavily on the experience of the test team. Much time is

01992 Elsevier Science Publishers Ltd

necessarily spent in familiarizing themselves with

the system when, in other test methodologies,

such a familiarization process is not always required.

Security testing is challenging work and can be satisfying to all those involved.

VIDEO REVIEW

Computer security -the movie

Computer Security from the Sunday Times

Computers in Business series of videos (c.45 mins)

Price: f 69.33

Publishers: Sunday Times Video Library, PO Box 169, Horsham, W. Sussex, RH13 SYL, UK; tel: +44 (0)403 42727.

“The business titles in the library provide a valuable service to industry by offering training

material of the highest quality at a price far lower

than expected. This means that you can afford to buy the programmes outright and use them again

and again instead of having to hire them.” So runs

the description on the back of the video box.

“Highest quality”, “far lower than expected“

(signi~cantly, not “the lowest”), “use them again and again”. . . The publicist was obviously not

afraid of calling a spade “a gardening necessity”.

And who is this reviewer to dispute the fact that the people appearing (who include Jill

Dando, Chris Hook of the NCC, Don Randall of the City of London Police Fraud Squad, Jan

Hrusks of Sophos, Robert Schifreen, Conoco plc

and Co-operative Bank and the production team),

are not the c&me de la c&me of their respective

fields? Or that RAF Uxbridge (the HQ of RAF

Fighter Command during World War II) is not a perfect backdrop for such a production? Or to

carp at the purchase price, which for many organizations may indeed be far lower than they expected. NO! He (your reviewer) must restrict himself to examining whether a prospective

purchaser would indeed use the video “again and

17

Documents

The security phase of software development