Information security management small systems security IFIP TC11 WG11 1WG11 2 seventh annual working conference on informat

This working conference brings together researchers and practitioners of different disciplines, organisations, and countries, to discuss the latest developments in amongst others secure

INFORMATION SECURITY MANAGEMENT

IFIP - The International Federation for Information Processing

IFIP was founded in 1960 under the auspices of UNESCO, following the First World Computer Congress held in Paris the previous year An umbrella organization for societies working in information processing, IFIP's aim is two-fold: to support information processing within its member countries and to encourage technology transfer to developing nations As its mission statement clearly states,

IFIP's mission is to be the leading, truly international, apolitica! organization which encourages and assists in the development, exploitation and application of information technology for the benefit of ali people

IFIP is a non-profitrnaking organization, run almost solely by 2500 volunteers It operates through a number oftechnical committees, which organize events and publications IFIP's events range from an international congress to local seminars, but the most important are:

• The IFIP W o rid Computer Congress, held every second year;

• open conferences;

• working conferences

The flagship event is the IFIP World Computer Congress, at which both invited and contributed papers are presented Contributed papers are rigorously refereed and the rejection rate is high

As with the Congress, participation in the open conferences is open to ali and papers may

be invited or submitted Again, submitted papers are stringently refereed

The working conferences are structured differently They are usually run by a working group and attendance is small and by invitation only Their purpose is to create an atrnosphere conducive to innovation and development Refereeing is less rigorous and papers are subjected to extensive group discussion

Publications arising from IFIP events vary The papers presented at the IFIP World Computer Congress and at open conferences are published as conference proceedings, while the results of the working conferences are often published as collections of selected and edited papers

Any national society whose primary activity is in information may apply to become a full member ofiFIP, although full membership is restricted to one society per country Full members are entitled to vote at the annual General Assembly, National societies preferring

a less committed involvement may apply for associate or corresponding membership Associate members enjoy the same benefits as full members, but without voting rights Corresponding members are not represented in IFIP bodies Affiliated membership is open

to non-national societies, and individual and honorary membership schemes are also offered

INFORMATION SECURITY

SYSTEMS SECURITY

IF/PTC11 WG11.1/WG11.2

Seventh Annual Working Conference on

lnformation Security Management & Sma/1 Systems Security September 30-0ctober 1, 1999, Amsterdam, The Nether/ands

Rossouw von Solms

Port Elizabeth T echnikon

Library of Congress Cataloging-in-Publication Data

IFIP TC11 WG11.1/WG11.2 Working Conference on Infonnation Security Management

& Small Systems Security (7th: 1999: Amsterdam, Netherlands)

Infonnation security management & small systems security : IFIP TC11 WG11.1/WG11.2 Seventh Annual Working Conference on Infonnation Security Management & Small Systems Security, September 30-0ctober 1, 19991 edited by Jan H.P Eloff [et al.]

Includes bibliographical references (p )

ISBN 978-1-4757-5483-4 ISBN 978-0-387-35575-7 (eBook)

Copyright© 1999 Springer Science+Business Media New York

Originally published by Kluwer Academic Publishers in 1999

99-40722 CIP

All rights reserved No part ofthis publication may be reproduced, stored in a retrieval system or transmitted in any fonn or by any means, mechanical, photo-copying, recording,

or otherwise, without the prior written permission of the publisher, Springer Science+ Business Media, LLC

Printed on acid-free paper

CONTENTS

Part one - Reviewed papers

1 A protocol improvement for High-bandwidth encryption 1 using non-encrypting Smart Cards

P.H SAMWEL, MARCEL SPRUIT

4 The Future of Australian & New Zealand Security 41 Standard AS/NZS 4444?

MA TTHEW W ARREN, BILL HUTCHINSON

5 The Effective Utilization of Audit Logs in lnformation 51 Security Management

WERNER OLIVIER, ROSSOUW VON SOLMS

6 An approach to standardizing security analysis methods for 63 virtual systems

ANN FRISINGER, LOVISE YNGSTROM

7 Information Security at Top Level- Securometer® 75 streamlines management information

ANDRE BUREN, BERT VAN DER MEER, ABBAS SHAHIM, WILLEM BARNHOORN, EDO ROOS LINDGREEN

MARCEL SPRUIT, P.H SAMWEL

9 A Secure Station for Network Monitoring and Control 103

V ASSILIS PREVELAKIS

Vl

10 Security aspects of a Java-servlet-based web-hosted e-mail 117 system

ELEANOR HEPWORTH, ULRICH ULTES-NITSCHE

11 Time as an Aid to lmproving Security in Smart Cards 131

VINCENT CORDONNIER, ANTHONY WATSON, SERGIY

NEMCHENKO

12 The Intranet Authorization Paradigm 145

MARK VANDENWAUVER, PAULASHLEY, GARYGASKELL

13 Predicting the Performance of Transactional Electronic 161 Commerce Protocols

MA TTHEW BERRY, ANDREW HUTCHISON, EL TON SAUL

Part two -Invited papers

14 The Cyber-Posture ofthe National Information

Infrastructure

WILLIS H W ARE

179

15 Principles oflris Recognition 205

MICHAELNEGIN, MACHIEL VANDERHARST

16 Designing a Secure System for Implementing Chip Cards 213

in the Financial Services Industry

This working conference brings together researchers and practitioners of different disciplines, organisations, and countries, to discuss the latest developments in (amongst others) secure techniques for smart card technology, information security management issues, risk analysis, intranets, electronic commerce protocols, certification and accreditation and biometrics authentication

W e are fortunate to have attracted at least six highly acclaimed international speakers to present invited lectures, which will set the platform for the reviewed papers Invited speakers will talk on a broad spectrum of issues, all related to information security management and small system security issues These talks cover new perspectives on secure smart card systems, the role of BS7799 in certification, electronic commerce and smart cards, iris biometrics and many more

AH papers presented at this conference were reviewed by a minimum of two international reviewers

W e wish to express our gratitude to all authors of papers and the international referee board W e would also like to express our appreciation to the organising committee, chaired by Leon Strous, for aU their inputs and arrangements

Finally, we would like to thank Les Labuschagne and Hein Venter for their contributions to this conference of WG 11.1 and WG 11.2, which was essential for its becoming a success

WGll.l (lnformation Security Management)

Chairman: Rossouw von Solms

E-mail: rossouw@ml.petech.ac.za

WG11.2 (Small Systems Security)

Chairman: Jan Eloff

E-mail: eloff@rkw.rau.ac.za

ACKNOWLEDGEMENTS

Organised by:

IFIP TC -11 Working Group 11.1 (lnformation Security Management)

and Working Group 11.2 (Smalt Systems Security)

Supported and sponsored by:

1NO (The Netherlands Organisation for Applied Sciences) CMG Finance, Division Advanced Technology

Concord Eracom ISACA NL chapter (lnformation Systems Audit & Control Association)

NGI (Dutch Computer Society) NGI SIGIS (Special Interest Group on Information Security) NOREA (Dutch Association ofRegistered EDP-Auditors)

Philips Crypto Sensar ISACA BeLux chapter NGI SIG EDP-Aidit

Conference General Chair

Jan Eloff, Rand Afrikaans University, South-Africa

Rossouw von Solms, Port Elizabeth Technikon, South-Africa

Programme Committee

Jan Eloff, Rand Afrikaans University, South-Africa

Rossouw von Solms, Port Elizabeth Technikon, South-Africa Rene Struik, Philips Crypto, The Netherlands

Jan Verschuren, 1NO-TPD-Effi, The Netherlands

Les Labuschagne, Rand Afrikaans University, South-Africa

X

Reviewers

Beatson, Jobn, New Zealand

Booysen, Hettie, South Africa

Caelli, Bill, Australia

Eloff, Jan, South Africa

Eloff, Mariki, South Africa

Gritzalis, Dimitris, Greece

Janczewski, Lech, New Zealand

Katsikas, Sokratis, Greece

Labuschagne, Les, South Africa

Longley, Dennis, Australia

MacLaine, Piet, The Netherlands

Pohl, Hartmut, Germany

Posh, Reinhart, Austria

Preneel, Bart, Belgium

Smith, Elme, South Africa

Van den Wauver, Mark, Belgium

Verschuren, Jan, The Netherlands

Von Solms, Basie, South Africa

Von Solms, Rossouw, South Africa

W arren, Matt, Australia

Organising Committee

Leon Strous, De Nederlandsche Bank, The Netherlands Wim Smith, TNO-FEL, The Netherlands Nelly van der Helm, TNO-FEL, The Netherlands

PARTONE

Reviewed Papers

A PROTOCOL IMPROVEMENT FOR BANDWITH ENCRYPTION USING NON- ENCRYPTING SMART CARDS

HIGH-Riidiger Weis

Praktilche lnfomaatiJc IV

Univer1ity of Mannheim, Gemaany

rweisGpi4.informatik.uni-mannheim.de

Abstract At the moment smart cards are the only practicable pretty secure place

to store secret keys But their physical properties limit the encryption bandwith Fortunately new cryptographic "Remotely keyed encryption" protocols support fast encryption on a slow smart card For the scheme described here, even a smart card without a built-in encryption function would do the job, e.g., a signature card (LuWe99] We also show a new interface-compatible security improvement to the RaMaRK scheme [Luck97), which needs only a light software modification on the host system The improvement provides better cryptographic security and makes a known plaintext attack by (BFN98] infeasible Furthermore, we discuss some new implementation aspects which provide a huge margin

crypto-graphic [Weis97] and many very dangerous hardware attacks [WKF97) have been developed, smart cards provide much higher security than other storage systems

J H P Eloff et al (eds.), Information Security Management & Small Systems Security

© Springer Science+Business Media New York 1999

2 Information Security Management & Small Systems Security

Because of physicallimitations, smart cards are typically slow tunately new cryptographic protocols make fast encryption on a smart card supported system possible

For-Smart cards are often designed to support authentication or digital signatures rather than encryption In this pa per, we concentrate on the RaMaRK protocol [Luck97] and show a new easy-to-implement security improvement

The RaMaRK protocol does not require the smart card itself to port encryption - support for hash functions, as built into many signa-ture cards, is sufficient In a world with many restrictions on the import, export or usage of encryption tools and far fewer restrictions regarding authentication or signature tools, this can be an important property

sup-2 REMOTELY KEYED ENCRYPTION

A remotely keyed encryption scheme (RKES) distributes the

compu-tational burden for a block cipher with large blocks between two parties,

a host and a card We think of the host as being a computer under the

risk of being taken over by an adversary, while the card can bea smart card, protecting the secret key We do not consider attacks to break the tamper-resistance of the smart card itself The host knows plaintext and ciphertext, but only the card is entrusted with the key

decryption protocol Given a B-bit input, either to encrypt or to decrypt,

depending on both the challenge value and the key

Lucks [Luck97] pointed out some weaknesses of Blaze's scheme and gave formal requirements for the security of RKESs:

(i) Forgery security: If the adversary has controlled the host for q -1

(ii) Inversion security: An adversary with (legitimate) access to cryption must not be able to decrypt and vice versa

en-(iii) Pseudorandomness: The encryption function should behave dorandomly for someone without access to the card, nor knowledge

pseu-of the secret key

While requirements (i) and (ii) restrict the abilities of an adversary with

ad-versaries without access to the card If an adversary could compute

A protocol improvement for High-bandwidth encryption using non-encrypting Smart Cards 3

forgeries or run inversion attacks, she could easily distinguish the cryption function from a random oneo

Keyed (RaMaRK) Encryption scheme, which uses severa! independent

scheme is provably secure if its building blocks are, i.eo, it satisfies the

mathematically any group operation would do the job as wello

We use three building blocks:

1 Key-dependent (pseudo-)random mappings

li: {0, 1}b -+ {0, 1}bo

H: {0, 1}* -+ {0, 1}bo

H has to be collision resistanto

30 A pseudorandom bit generator (i.eo a 'stream cipher')

S: {0,1}b -+ {0,1}*0

8(8) have tobe indistinguishable from randomly generated bitso

In addition to pseudorandomness, the following property is needed:

If 8 is secret and attackers choose t1 , t2 , o o o E {0, 1}b with ti '/:- t;

for i '/:- j and receive outputs 8(8 $ t1), 8(8 $ t2), o o o, it has tobe infeasible for the attackers to distinguish these outputs from inde-pendently generated random bit strings of the same sizeo Hence, such a construction behaves like a random mapping {0, 1}b -+

on the secret 8 o

Based on these building blocks, we realize a remotely keyed encryption

where

(P,Q,R),(A,B,C) E {0,1}b X {0,1}b X {0,1}B-2bo

4 Information Security Management & Small Systems Security

Figure 1.1 The RaMaRK encryption protocol

For the protocol description we also consider intermediate values

T, U, V, X, Y, Z E {0, l}b, and I E {O, l}B-2b

The encryption protocol works as follows:

1 Given the plaintext (P, Q, R), the host sends P and Q to the card

2 The card computes U = fi(P) $ Q and T = h(U) $ P,

and sends X= fs(T) $ U to the host

3 The host computes I = S(X) $ R and Y = H(I),

sends Z =X$ Y to the card, and computes C = S(Z) $ I

4 The card computes V= j4(T) $ Z,

and sends the two values A = f5 (V) $ T and B = f6 (A) $V to

the host

Decryption is dane similarly The description of decryption is omitted here to save space

If the block size B of the cipher it realizes is not too small compared

to the parameter b, the RaMaRK scheme is effi.cient The card itself operates on 2 · b bit data blocks, and both 3 · b bit of information enter and leave the card

A protocol improvement for High-bandwidth encryption using non-encrypting Smart Cards 5

Blaze, Feigenbaum (AT&T) and Naor (Weizmann Institut) [BFN98] published recently a paper on the EUROCRYPT'98 which has showed a new formal model for RKES, found a problem in the RaMaRK protocol and suggested a new RKES, that fulfills the new security model

PSEUDORANDOMNESS OF A RKES

It is theoretically desirable that a cryptographic primitive always pears to behave randomly to everyone without access to the key In any RKES, the amount of communication between host and card should be less than the input length, otherwise the card could just do the complete encryption on its own Since ( at least) a part of the in put is not handled

ap-by the smart card, and, for the same reasons, ( at least) a part of the output is generated by the host, an insider adversary can easily decide that the output generated by herself is not random

Blaze, Feigenbaum, and Naor [BFN98] found another way to define the pseudorandomness of RKESs Their formal definition is quite com-plicated It is based on the following scenario:

Adversary A is gains direct access to the card for a certain amount of time and makes a fixed number of interactions with the card Ones A

has lost direct access to the card, the encryption function should appear

to behave randomly, even to A

SCHEME

Regarding the RaMaRK scheme they pointed out that an adversary

A who has had access to the card and lost the access again, can later

choose special plaintexts where Acan predict a part of the ciphertext This makes it easy for A to distinguish between RaMaRK encryption and encrypting randomly

The intermediate value X depends only on the (P, Q)-part of the

plaintext, and the encryption of the R-part depends only on X If A

chooses a plaintext (P, Q, R), having participated before in the tion of (P, Q, R'), with R =/= R', the adversary Acan predict the C-part of the ciphertext, but not the P nor the Q part, corresponding to (P, Q, R)

encryp-on her own

Thus, according to the definition of [BFN98], the RaMaRK scheme is not pseudorandom

6 lnformation Security Management & Small Systems Security

Further the authors of [BFN98] pointed that there is a possibility to

"However, because the encryption key depends only on the first two

plaintext blocks, an arbitrarily large set of messages ali of which start

with the same two blocks will always be encrypted with the same key

This is not a hypothetical situation: A set of files in a computer ffie

system, for example, might always start with the same few bytes of

structural information

actually feasible The authors of [BFN98] continue:

An adversary that controls the host during the encryption or

decryp-tion of one file in such a set could subsequently decrypt the encrypdecryp-tion

of any file in the set."

interme-diate key Z (resp X for decryption) depends on all bit of the plaintext

(P,Q,R) (resp ciphertext (A,B,C))

Z =X EB Y =X EB H(I) =X EB H(lli]EB S(X))

sufficient for a decryption of any file of the mentioned set of files

On the other hand it is a not satisfactory cryptographic property that

an attacker can peel off one of the two stream cipher encryptions if she

knows the intermedia te key X

C = I EB S(Z) = R EB S(X) EB S(Z)

Since there are sever al advantages of the RaMaRK scheme, the author suggests a slight modification of the protocol on the host side

We want to make sure that also the intermedia te keys X and Y depend

P := P EB h(R) and Ă :=A EB h(C)

The Improved RaMaRK scheme is interface-compatible with the

un-modified RaMaRK scheme So no hardware modifications to the smart card are necessary

A protocol improvement for High-bandwidth encryption using non-encrypting Smart Cards 7

Figure 1.2 Improved RaMaRK

LIMITATIONS

If we choose a standard hash function with 160-bit output, a known plaintext attack against the pseudorandom property seems to be infea-sible

According to Lucks, a chosen plaintext attack in the BFN scenario

to distinguish the output of the protocol from a random output is still feasible So even the improved RaMaRK scheme does not meet the stronger security model of [BFN98]

Further more it is not possible to peel off one stream cipher encryption

as discussed in the last section

The modification requires two expensive hash function calls for the big block B We do not expect this to cause a problem for most applications

since the main bottleneck seems to be the communication with the card But if our improved scheme leads to performance problems on the host,

we suggest using a fast, non-cryptographic hash function

8 Information Security Management & Small Systems Security

5.3 REMARKS ON THE BFN AND ARK

SCHEMES

Lucks has recently published a new Accelerated Remotely Keyed cryption (ARK) scheme [Luck99] which fulfills the BFN security model The ARK scheme offers better performance and non-asymptotic security proofes

En-Note that all schemes in [BFN98] and [Luck99] are pseudorandom

ciphers)- and thus are designed for smart cards with built-in encryption

6 IMPLEMENTATION OF BUILDING

BLOCKS ON THE HOST

Hash Functions In order to combine the big block of data with the small blocks in the card we need a collision-free hash function The calculation is performed on the host, so we can simply choose a well-tested hash function like SHA-1 or RIPE-MD160 Both produce a 160-bit output, which seems to provide sufficient security

Pseudo Random Bit generators In [Luck97] the use of a stream cipher was suggested But we can also use a well-tested block cipher in the OFB or CFB mode (E.g CAST-5 performs very fine even on small packets [WeLu98])

7 HASH BASED PRM

In this section we discuss how to realize Pseudo Random Mappings (PRM) with a Non-Encrypting smart card One promising idea for realizing PRM on a smart card is to use a hash-based MAC function

then we define

HMACK(x) = 1l(K $ opadll1l(K $ ipadllx))

This approach has several advantages Cryptographic hash functions have been well studied; they are usually faster than encryption algo-rithms It is easier in many countries, to export or import an authen-tication tool, such as a signature system, than to export or import an encrypting system

A protocol improvement for High-bandwidth encryption using non-encrypting Smart Cards 9

Security of HMAC

In [BCK96] it was proven that HMAC provides security against sion and forging attacks with only weak assumptions on the underlying hash function

colii-This leaves an additional margin of security: even if some weakness

in the hash function H (e.g MD5) is found, the MAC based on H may stiH be secure For example, a collision of hash function means finding

a collision with a fixed Initial Vector (IV) and known output If an attacker wants to find collisions in HMAC, he must find a collision in the underlying hash function even when the IV is random and secret, and the hash value is not explicitly known

HMAC based on SHA-1 or RIPE-MD160 provides a 160-bit output

So even birthday attacks which need 280 operations seem tobe infeasible Note that a MAC based on a standard 64-bit block cipher (e.g Triple-DES) is insufficient Even MAC based on AES, which will be a 128-bit block cipher, cannot be recommended for high-security applications

Acknowledgments

The author thanks Stefan Lucks for his critica! remarks on the security of our protocol modification and implementation aspects and Wolfgang Effelsberg for many helpful comments on building the final version of this pa per

References

[BCK96] Bellare, M., Canetti, R., Krawczyk, H., "Keying hash

functions for message authentication", Advances in Cryptology Crypto 96 Proceedings, Springer, 1996

-[Blaz96] Blaze, M., "High-Bandwidth Encryption with

Low-Band-width Smartcards", Fast Software Encryption (ed D mann), Springer LNCS 1039, 33-40, 1996

Goll-[BFN98] Blaze, M., Feigenbaum, J., Naor, M., "A Formal Treatment

of Remotely Keyed Encryption (Extended Abstract)",

Euro-10 Information Security Management & Sma/1 Systems Security

crypt '98, Springer LNCS 1403, 1998, pp 251-265

[DBP96] Dobbertin, H., Bosselaers, A., Preneel, B., "RIPEMD-160, a

strengthened version of RIPEMD", Proc of Fast Software Encryption (ed D Gollmann), LNCS 1039, Springer, 1996 [FIPS180] NIST, "Secure Hash Standard", Washington D.C., April

1995

[GeWe98] Geyer, W., Weis, R., "A Secure, Accountable, and

Collabora-tive Whiteboard", Proc of IDMS '98, Oslo, Springer LNCS,

1998

[Luck97] Lucks, S., "On the Security of Remotely Keyed Encryption",

Fast Software Encryption, (ed E Biham) Springer LNCS,

1997

[Luck99] Lucks, S., "Accelerated Remotely Keyed Encryption", Fast

Software Encryption, Springer LNCS, Rome, 1999

[LuWe99] Lucks, S., Weis, R., "Remotely Keyed Encryption Using

Non-Encrypting Smart Cards" USENIX Workshop on Smartcard Technology, Chicago, May 10-11, 1999

[LWH99] Lucks, S., Weis, R., Hilt, V., "Fast Encryption for Set-Top

Technologies", Multimedia Computing and Networking '99, San Jose, 1999

[Weis97] Weis, R., "Combined Cryptoanalytic Attacks against

Signa-ture and Encryption schemes" (in German), A la Card aktuell 23/97, S.279, 1997

[Weis98a] Weis, R., "Modern Block Ciphers" (in German), in:

"Kryp-tographie", Weka-Fachzeitschriften-Verlag, Poing, 1998 [Weis98b] Weis, R., "Modern Stream Cipher" (in German), in: "Kryp-

tographie", Weka-Fachzeitschriften-Verlag, Poing, 1998 [Weis98c] Weis, R., "Cryptographic One-Way-Functions" (in German),

in: "Kryptographie", Weka-Fachzeitschriften-Verlag, Poing,

1998

[WKF97] Weis, R., Kuhn, M., Floricic, B., "Hacking Chipcards",

Work-shop CCC '97, Hamburg 1997

[WeLu98] Weis, R., Lucks, S., "The Performance of Modern Block

Ciphers in JAVA", Preproceedinges Cardis'98, Neuve, Proceedings (ed Quisquarter, Schneier) will appear in Springer LNCS, 1998

Louvain-la-Real-time Risk Analysis on the Internet

A Prototype

H.S VENTER (heins@icon.co.za)

L LABUSCHAGNE (ll@na.rau.ac.za)

J.H.P ELOFF (eloff@rkw.rau.ac.za)

Department of Computer Science

Rand Afrikaans University

Key words: Internet security, Real-time Risk Analysis (RtRA), network, firewalls, TCPIIP

packet, RtRA prototype

Abstract: In current times, sending confidential data over the Internet is becoming more

commonplace every day The process of sending confidential data over the Internet is, however, concomitant with great effort: encryption algorithms have

to be incorporated and encryption key management and distribution have to take place Wouldn 't it be easier, more secure and faster if only technology could be introduced to do risk analysis in real time? The objective of doing risk analysis in real time is to tind a method through which dynamically to determine the vulnerability of, for example, a TCPIIP packet in terms of generic threat categories such as interception and fabrication Once the vulnerability of the packet has been determined, the appropriate

countermeasures can be activated to secure the packet before it is sent offto its original destination The countermeasures are activated according to certain data that is found in and extracted from the TCPIIP packets In order tobe able to obtain this data, each TCPIIP packet flowing through a certain point in

a network is intercepted and analysed

A paradigm shift has taken place in the commercial sectors of most first-world countries during the past decade With the advent of the Internet, most organisations are rethinking their business strategies to exploit the biggest single quantum leap in

J H P Eloff et al (eds.), Information Security Management & Small Systems Security

© Springer Science+Business Media New York 1999

12 lnformation Security Management & Sma/1 Systems Security

technology for many years In the race to fmd new competitive advantages, some important issues are, however, slipping through the proverbial cracks One such issue is Internet security

Most security professionals agree that it is very difficult to detect an attack until

it is almost too late As soon as a message leaves the organisational domain, ali control is lost over it It is not possible with absolute certainty to predict what attacks will be launched at the message while in transit over the Internet Security measures can only be applied to the message based on a wide range of potential security threats, for example, eavesdropping or interception It is for this reason that the vulnerability of a message, rather than the potential threat thereto, is used to determine the security services required to protect it

The vulnerability of a message comprises ali the factors that influence it, for example, its origin, content and destination Determining the threat to a message has, however, become more difficult, as there are many unknown factors beyond the boundaries of the organisational domain Examples of such unknown factors are the route the message will follow, the people who might benefit from attacking the message and whether or not the message has been compromised in any way

Internet security used to manifest itself in a form that could only be described as rather "static" This means that it stilllacks a network-security paradigm in terms of which real-time enhancements can be made to its network security Is there perhaps not an easier, faster and more secure way than that provided by current security technologies? Although the ultimate network-security solution still is far from a reality, this article will be devoted to an attempt at showing that a technology, called

Real-time Risk Analysis, can go a long way towards finding the answer to this

question

A method is, therefore, required dynamically to determine the vulnerability of a message according to its generic threat categories such as interception and fabrication [PFLE 89] Once the vulnerability of the message has been determined, the appropriate countermeasures can be activated, in real time, to secure it during its transmission to its destination This entire process must, however, take place in real time and must be absolutely transparent to the user For the process to be transparent to the user, it must execute at the network level One possible method

Real-time Risk Analysis on the Internet: a prototype

FIREWALLS

13

Because of the simplicity of TCPIIP and the clamant need for more secure networks, additional security measures must be implemented - security measures that will enhance network security dynamically and in real time In the light of the lack of such security analysis technologies, the concept "RtRA" had to be developed Another reason why RtRA had to be introduced is the dynamic and ever-changing nature of computer networks and technical aspects, such as new developing architectures Although conventional risk analysis can, therefore, be effected on computer networks, it will never be implemented exactly as planned, owing to the changeable, dynamic nature of computer networks and architectures RtRA constitutes that process through which dynamically and in real time to determine the vulnerabilities, threats or risks that may possibly be incurred when sending data over the Internet, as well as that process through which to fmd ways in which, at best, to prevent or, at worst, to minimise these vulnerabilities, threats or risks [LABU 98] The closest conventional solution to RtRA until now is that technology which is generally encompassed by the term "firewalls" RtRA technology could, however, constitute a more revolutionary solution RtRA technology differs from the firewall approach in the sense that frrewalls will treat two successive TCPIIP packets in exactly the same manner, because of its predefmed rules The characteristics of two successive TCPIIP packets may, however, differ vastly from each other, since packets do not necessarily arrive in a set order at a certain point in a network In addition, the packets flowing through a certain point in the network will most likely consist of a mixture of various messages sent from different places at different times It is in the latter respect that RtRA technology is set significantly to facilitate the real-time packet-analysing effect Following, a detailed description of existing firewall technology

2.1 Existing firewall technology

A frrewall provides a blockade between a secure, internat and private network and an insecure one, such as the Internet [IBMC 97] It protects the internat network from other networks in the Internet, while at the same time allowing TCPIIP services (such as e-mail, HTTP and FTP) to access hosts outside the network - on the Internet This type of frrewall will henceforth be referred to as a

"conventional frrewall"

Currently, three different types of conventional frrewalls are being distinguished:

• Monitoring - This type of frrewall simply logs traffic going into and out of a server

• Packet-filtering (sometimes referred to as "screening") - This type of firewall filters packets by using various protocols that, in turn, determine which incoming and outgoing IP addresses, domains, names or passwords are acceptable This operation, in effect, blocks out undesirable or unrecognised incoming traffic and limits the extent and routing of outgoing traffic

• Stateful inspection (also called "proxy servers" or "application-level gateways")

- This type of firewall controls ali traffic with strict protocols, including levels of

14 lnformation Security Management & Sma/1 Systems Security

access or maintaining regular checks of ali data trials or communications This type of frrewall is the most advanced and, when strictly enforced, it can exert a strict level of control over and knowledge about the use of the organisational server

Examples of conventional frrewall products are CheckPoint's Firewall-1 [FIRI 99], TIS's Firewall Toolkit [FWTK 99] and Raptor Firewall [RAPT 98]

Although a conventional firewall is a highly effective way of effecting network security, conventional frrewall technology does not determine risk values for each TCPIIP packet or message in real time This implies that a new generation of frrewall technology is required

Before looking at this new generation of frrewall technology, we need, however, frrst to consider conventional frrewall technology, as depicted in fig 2.1 below This figure represents a complete scenario, in terms of which the TCPIIP packet travels between two workstations

Frames 1 and II in fig 2.1 below represent the potentially secure network protected by the firewall FW in frame Il, while frame III represents the TCPIIP packet (DG) that flows between Network 1 and Network 2 Note, in this respect, that DG also is present in frames 1, II, IV and V Frame IV represents the Internet-the insecure path along which the TCPIIP packet travels to get from Network 1 to Network 2, for example Frame V represents an insecure network with no frrewall

Network 1 : This is a secure, private network lhat

implements a conventional 6rewan

N etwork 2 : This is an ordinary private network with

no network security

Figure 2.1: Conventional firewall technology

The functionality offered by conventional frrewalls can be ascertained by looking at an example of one of the most recent developments in conventional frrewall techn,ology, namely the Raptor Eagle Firewall5.0 [RAPT 98] Raptor Eagle Firewall 5.0 is a high-performance, full-security enterprise firewall [RFAQ 98]

Real-time Risk Analysis on the Internet: a prototype 15 Based on application-level proxies, the firewall comhines a high level of perimeter security Some ofits specific functions are as follows [EAGL 98]:

• Use of rules at the application level: Raptor denies any connections not explicitly allowed hy a rule Each rule can incorporate a range of criteria, including source and destination addresses, type of service, strong user or group authentication and the exact time of the access attempt

• Automatic Suspicious Activity Monitoring (SAM): Raptor performs SAM on all connections throughout the firewall SAM works hy keying on thresholds estahlished for connection rates when formulating authorisation rules Raptor applies these thresholds on a rule-hy-rule hasis In creating rules, their thresholds are specified, hased on anticipated levels of access for each of them

• Transparent access through the firewall: Raptor can support transparent connections hetween internat and extemal hosts The term "transparency" refers

to a user's awareness of the frrewall The firewall can he configured in such a way that users can connect through it to a destination system, stiH suhject to existing authorisation rules, without heing aware of the presence of the firewall This is the most important and recent functionality in conventional frrewall technology How will this scenario change, however, if the new generation of frrewall technology were to he added? The concept "new generation firewall" entails the expansion of conventional frrewall technology with additional modules to implement RtRA Before considering the RtRA process, however, a hrief discussion

on how TCPIIP packets and sessions are analysed in terms of this new generation frrewall technology

2.2 Analysing a TCPIIP session

A communication session hetween two hosts consists of different levels, with the

communication session itself acting as the first level Furthermore, a communication session could consist of a few messages that could each he hroken

up into TCPIIP packets A message serves as the second level and a TCPIIP packet

serves as the third level in a communication session, as depicted in fig 2.2 helow There hasically are two approaches to analysing a communication session, namely that at message level and that at packet level Both approaches have certain advantages and disadvantages, however When analysing the communication session at message level, the vulnerahility and security countermeasures of the message will he determined in terms of the entire message This, in turn, means that the message will only he analysed hefore commencement of transmission to determine the countermeasures, just hefore the message is hroken up into packets This also means that the same countermeasures will he applicahle to all of the TCPIIP packets into which the message bas heen hroken up, hecause all the packets will relate to the same message The advantage of following the message-level approach is that it is faster than the packet-level approach, as the countermeasures have already heen determined for the entire message and only need to he applied to each packet of the message A disadvantage or shortcoming of the message-level approach, however, is the fact that limited potential ground is won towards RtRA

In fact, conventional frrewall technology follows almost a similar approach to accomplish this The hasis on which a conventional firewall functions is also founded on predefined countermeasures and rules A conventional firewall, in other

16 lnformation Security Management & Sma/1 Systems Security words, applies security more at user level (for a specific IP address), and not at message level

Levell: Communkation session

Figure 2.2: Layering in a communication session

By following the packet-level approach, the workload increases, as each TCPIIP

packet can be individually encrypted while being transmitted [FORD 97} This is owing to countermeasures that are determined for and applied to each TCPIIP packet

as an entity before the next packet is analysed, thus resulting in a slower process Despite the cost of an increased workload, however, some benefits may be derived, such as the fact that analysing packets is not bound to a session any more In this way, any packet can be analysed, regardless of its type, the connection from which it

is coming or the order in which it arrives A packet-filtering firewall functions in almost the same way in the sense that packets are also analysed in this manner Only the packet-level approach will, however, be considered for the purposes of this article, so that more emphasis could be placed on the real-time effect of RtRA and its advantages, while keeping the explanation as simple as possible The authors are, however, aware of the fact that, in following this approach, they did not opt for the best way in which to implement RtRA A combination of the message-level and the packet-level approaches would, for instance, offer a better solution By implementing both these approaches, room would be left for optimisation An example of how optimisation could play a prominent part in this scenario is the following: if it were known that a message was very long, it would make more sense rather to follow the message-level approach, as it would save more time (a new countermeasure would not need to be determined for each packet) If, however, the real-time effect and higher security were considered to be of greater importance, it would be better to follow the packet-level approach Following, a discussion on the RtRA process and its modus operandi

Real-time Risk Analysis on the Internet: a prototype 17

2.3 The RtRA process

The modus operandi of the RtRA process is as foliows: a risk value is determined for each TCPIIP packet traveliing through a monitored point in a network in real time This risk value is determined as foliows: certain fields are extracted from the TCPIIP packet as they are intercepted at the monitored point, for example, the source-address field, the destination-address field and the time-sent

field First, a risk value for each of these fields is determined and consolidated into

an overali risk value for the TCPIIP packet Based on this risk value, certain security services are activated dynamicaliy to reduce the vulnerability of the packet This has the effect that two consecutive packets with the same source and

destination fields can have different risk values, because their time-sent fields indicate that they have been sent at different times The frrst packet could, for example, have been sent a fraction before a time threshold value change As soon as this threshold value changes, it causes the risk level of the time-sent field to change for each packet to be sent from that point onwards The second packet could have been sent a fraction after this threshold value has changed, thereby causing the second packet either to have a higher or a lower risk value This will also cause the overali risk value determined for the TCPIIP packet to change The other packet is, therefore, treated differently

The RtRA process proposes that ali network traffic is analysed, but the appropriate security level is only applied to the TCPIIP packets according to the packets' determined vulnerability level This means that not ali packets are necessarily secured ( encrypted) since not ali packets are vulnerable or sensitive packets This does not seem normal since people mostly secure their systems in advance However, it simply is impossible to secure every TCPIIP packet travelling through a network, because the overhead and processing power acquired would simply be too high sin ce millions of packets can travel throughout a network in only fractions of time

RtRA may seem to relate to intrusion detection Shortly, an intrusion detection system (IDS) monitors a system or network constantly with the goal to report intrusion attacks This is done by monitoring users' whereabouts in a system, for example, number of attempted logins, activities by users, system resource usage etc This data forms a footprint of network and system usage over time From this footprint, the IDS will compute metrics about the system's overali state and decide whether an intrusion is currently occurring [PRIC 98] Although RtRA also monitors the network, it takes the process a little further An IDS only detects a possible intrusion attack as soon as the attack occurs RtRA, however, attempts to secure communications even before a potential attack can occur by applying appropriate countermeasures in advance to ţhe appropriate TCP liP packets and sessions in real time In addition, RtRA's effectiveness level is constantly at a maximum as soon as it is installed, but that of an IDS increases with time

The approach followed for the implementation of RtRA is that two new additional modules be added to conventional frrewall technology (FW), implementing RtRA as foliows These two additional modules are calied the

"Gateway module" (GW) and the "Countermeasure Executor module" (CE) respectively Together, they are referred to as the "Gateway Bridge" (GB), as

18 Information Security Management & Sma/1 Systems Security

depicted in fig 2.3 In addition, combining FW, CE and GB forms the "New Generation Firewall" (NGF) Note that frames I and II of fig 2.1 change as follows

in fig 2.3 Based on the above, a more detailed explanation ofwhat RtRA is will be given by means of a prototype in the next section

r

1 CE 1 -

FW: Convenliona16rewall CE: Countermeasure Executoc

NGF: New Generalion Firewall GB: Gateway Bridge

Figure 2.3: Conventional firewall expanded to the NGF

This section will be devoted to an attempt at demonstrating the essential RtRA concepts, for which purpose a prototype has been constructed

Referring to RtRA as a "new generation" in firewall technology (NGF), implies

that the concept forms part of an already existing concept, namely that of firewalls

As was mentioned earlier, the concept of a firewall has, however, been expanded into a more intelligent version of a firewall by merely adding certain intelligent modules that will be able not only to analyse the communication session in real time but also to do so in an intelligent fashion The two main modules are GW and CE

GW can, in turn, be broken up into three smaller modules:

• Module 1: Monitor

• Module 2: Risk analyser

• Module 3: Route finder

The output of one module serves as the input for the next consecutive module

In fig 3.1, a basic configuration ofthe prototype is given Frames M1, M2 and M3

show where the respective activities of Module 1, Module 2 and Module 3 take

place

Real-time Risk Analysis on the Internet: a prototype

M2: Module 2 - Risk analyser

M3: Module 3 - Route finder

N etwork 1 : This is a private network

that makes use ofRtRA

N etwork 2: This is an ordinary private

network with no network security S: Server without 6rewall

FW: Conventional 6rewall DG: TCPIIP packet

Figure 3.1 : GW expanded

19

Module 2 is the more comprehensive module, because it is in this module that

the critical processing of the prototype is performed Although the functionality and processing of Module 1 (M1) and Module 3 (M3) are less comprehensive than that

of Module 2 (M2), ali three modules are equally important for the execution of the

prototype Following, a more detailed discussion ofthe three modules

3.1 Module 1 - the monitor

The principal aim ofthis module is to analyse a TCPIIP packet in a bid to obtain the information necessary to perform RtRA This will be achieved by intercepting each TCPIIP packet in a single session and by extracting the required fields from each packet A session is the duration for which two workstations are connected to and the period during which they exchange data with each other The latter data is sent to Module 2 for further processing

What exactly is a TCPIIP packet? It is a unit or "package" of information that contains a portion of a greater chunk of data Furthermore, data such as that contained in e-mail messages and Web pages is sent across the Internet using packets [INTE 98]

The inputs for Module 1 are the TCP/IP packets, while its outputs are the

appropriate extracted fields A graphic illustration of how a TCPIIP packet (which

is the input to Module 1) is composed, is presented in fig 3.2 This is a single

20 lnformation Security Management & Small Systems Security

TCPIIP packet that travels between two workstations on the Internet The fields extracted for the prototype (which constitute the input to Module 2) appear in bold print and are considered the most important fields (for the purpose ofthe prototype) The reason for only using them in the prototype will be explained next [P ABR 96]

Prot 1 Head 1 Type of service

verston length T o tai len&th

Packet ID (number) ~1~1 Fragment olfset

IP source address

IP destination address Options

Sequence number Acknowledgement number Data 1

offset ~~~~~el~ls Window

Checksum Urgent pointer

Option type 1 Option lencth Maximum segment size

Figure 3.2: TCPIIP packet- extracted fields

The Total-length field indicates how many bytes the totallength of the message consists of and, from this field, one can distinguish what type of message it is A short length may, for example, indicate that it is an SMS cellular-telephone message (160 characters maximum) or, if longer, it may indicate e-mail messages or even a file or document transfer By keeping track of Web statistics using some Web-monitoring software, one could easily determine the average length of e-mail messages sent for a specific organisation This average can then be used as a threshold value for the Total-length field If the total length of a message were significantly to exceed this average, a higher risk factor will become applicable to the message forthwith It could, for example, be an indication that large chunks of information are in the process of being insecurely transferred The greater the margin by which the message length, therefore, exceeds the average message length, the higher the risk that some extraordinary message is in transit ( either insecurely exported by an inside employee or insecurely downloaded by an outsider)

The Time-to-live (sometimes referred to as the "time-sent") field indicates how long the packet has been travelling from the sender to the receiver and serves as a

Rea/-time Risk Analysis on the Internet: a prototype 21

timer, although the value is only incremented each time it reaches another host (ora

"hop") In this way, this field indicates how long the packet has been travelling and, from that, one could determine whether or not the packet was sent inside or outside a valid threshold Time to live If, for example, the threshold value were exceeded, it could, therefore, indicate a possible packet interception or modification

The IP source address and the IP destination address, as well as the TCP source port and the TCP destination port, provide information from and to whom the packet is sent From the data in these fields, one could determine whether or not

a packet was sent to or from the correct computer/person

The Options field also contains valuable information, among which details on how loose or strict the routing of the packet is If a packet were routed very strictly,

it would carry a lower risk ofbeing a malicious packet

3.2 Module 2 - the risk analyser

The purpose of this module is to determine the level of risk associated with each packet in the current communication session If RtRA were done for the entire communication session, a value would only have been obtained after the communication session has been completed- which would, naturally, have been too late! Say, for example, a time threshold value is 5:00 pm and that a connection between two workstations has been established at 4:57 pm, lasting until5:49 pm At 5:00 pm, the risk level for the Time-to-Iive field changes to that of a higher risk level This will have the effect that, in the latter part of the said communication session, a more effective countermeasure will have tobe activated at 5:00 pm To determine a risk value for the first packet and then to apply it to the entire communication session would also not work, as the risk level would be appropriate for the first three minutes ofthe connection, but would have changed from 5:00 pm

to 5:49 pm, because of the time threshold value of 5:00 pm The risk value determined for the first packet would, therefore, not be appropriate for the greater part of the session This, in turn, means that the real-time effect will be completely lost and that the countermeasures would be rendered ineffective

The inputs to Module 2 are the outputs from Module 1 - the extracted fields from the current TCPIIP packet- that were intercepted at the Gateway (GW) The output of Module 2 is a Global Risk Value (GRV) A GRV is a value determined to specify the overall risk value associated with a current TCPIIP packet in order to allocate the right degree of security to such packet An Inference Engine (lE) determines a GRV by consolidating the extracted fields from the TCPIIP packet into

a single value, namely the GRV The consolidation method determines to what extent these extracted fields comply with characteristics in two databases, called a

Rule Base (RB) and a Knowledge Base (KB)

The RB, KB and an lE are the three sub-modules of Module 2 Note, however, that although the RB and the KB form sub-modules of Module 2, they are "read-only" in respect of the RtRA prototype In addition, the RB and KB are databases that are updated by a system administrator The components of Module 2 are depicted in fig 3.3 as follows:

22 lnfonnation Security Management & Smal/ Systems Security

1 M2: Module 2 - Risk analyser

1 M3: Module 3 - Route fmder

' , ,l, 1 N etwork 1: This is a Private network

, 1 that makes use ofRtRA

"'- _ - ~ N etwork 2: This is an ordinary private _ _ _ _ _ _ _ _ _' ~ network with no network security

1 Exlemaltempor"'Y S: Server without firewall

1

Knowledee 1 Rule 1

Bue Ba se M3 1

The Knowledge Base (called "KB" for short) is a database consisting of entries that provide information on the organisation The KB operates on information based

on the extracted fields ofthe TCPIIP packet from Module 1 As an example, a risk level can be determined for each type of IP address An executive will be allocated with a higher risk level than that allocated to an operator It is also possible to determine a risk value based on the location of a workstation A mobile workstation (for example, a notebook) will incur a higher risk than a protected workstation securely locked up in an oftice somewhere

Risk values are allocated to each entry in the KB KB values can be perceived

to remain relatively constant for different organisations in the same market sector

Another important concept of the Knowledge Base is the concept of global risk

countermeasures Symmetric key encryption is, for instance, used as a baseline

stronger security is required (high GRV) lf a GRV were low (were to have a low

risk value), rninimum-security countermeasures would be applied to the packet Risk levels can, however, be refined to include multiple levels, for example, low, medium-low, medium, medium-high and high

Real-time Risk Analysis on the Internet: a prototype 23

The Rule Base (Called "RB" for short) contains information that is specific to an organisation - it differs from one organisation to the next, regardless of whether two organisations are in the same market sector The reason for this is that the RB reflects the current situation in an organisation; the values in the RB are, therefore,

quantitative

An example of an RB entry is that IP address www.xxx.yyy.zzz belongs to person X Another example is that the IP address aaa.bbb.ccc.ddd belongs to a mobile computer From the above, it is clear that the values www.xxx.yyy.zzz and

aaa.bbb.ccc.ddd are quantitative values, for example, an IP address varies in

quantity: 152.106.42.155, and 152.106.42.156 are two IP addresses that follow quantitatively on each other The values in the KB examples above (high risk,

medium risk and low risk) are qualitative values, because they indicate the quality of

the risk in question

Another important function of the RB is to specify what the quantitative value is for each appropriate risk level that has been determined This is referred to as the risk level activation RB (see fig 3.4) A GRV between O and 3.4 (for a scale out of 10) is, for example, is considered to be a GRV with a low risk level A GRV between 3.5 and 5, in turn, is considered tobe a GRV with a medium risk level A GRV between 5.1 and 10, on the other hand, is considered tobe a GRV with a high risk level Should a GRV be fixed at, for example, a value of 4, the medium-level-

of-risk countermeasure will be activated This will have the effect that symmetric

key encryption will be executed

The lE is at the heart of the prototype It uses the outputs from Module 1, together with the KB and RB, to determine an Interim Risk Value (IRV) for each field extracted by Module 1 An IRV is a risk value that is determined for each field extracted from the TCPIIP packet This takes place just before the consolidation process to determine the GRV (see fig 3.4) In other words, an IRV is, in essence, determined in the same way as a GRV, with the exception that it merely serves as an in-between process to obtain a single risk value for each extracted field Consider, for example, the extracted field "TCP source port" It is found tobe P in fig 3.4 From P, two characteristics have been derived: Pisa reserved port, resulting in a risk value of 7 In addition, P normally operates in an Operating System W environment, resulting in a risk value of 5 In order to obtain a single risk value for

P, 7 and 5 have tobe consolidated, resulting in an IRV of6

These IRVs are then consolidated to obtain the GRV for each TCPIIP packet that passes through GW There are different and complex ways in which actually to

consolidate the IRVs into a GRV, for example, the concept offuzzy logic [DERU

97] In the current version ofthe prototype, however, the consolidation ofthe IRVs into a GRV will simply be done by calculating the averages ofthe IRVs

24 lnformation Security Management & Sma/1 Systems Security

A representation ofthe steps tobe followed in the lE is provided in fig 3.4

lnference Engine (IE)

lliCOmii!C p :~ot TCPIIP CD 1 tll 1 rn 1 @ 1 ~ 1 ® 1 (!) 1 (j) 1 ®

RBir ~••.ccc w.l oee.ftJ.ca.JoJ.h iil.Jij.kkk.lll tJl

Ponon X Ponon Y Ponon Z RB% t 1\onon X 1\onen Y

~: - CRVt-.,;,.; GRV - M.""ii~ CRV -Wch CRV- (ii

Cnntu- NoN Syrnmetric key P!Mte key m.- -o.l.i -:r.,:-, 6.i:io "CD

Low GRV Modilm GRV Hich GRV

JnaUllftll ~~.n~:ryption e.ncryption

Figure 3.4: The various steps in the risk analyser (Module 2)

Fig 3.4 illustrates the nine steps tobe set out next Each frame in the lE section

of fig 3.4 is numbered according to the specific step with which it is associated In the bottom section of fig 3.4, parts of the KB and RB are given The numbers in each frame of the KB and RB indicate the step with which the specific KB or RB is associated Read fig 3.4 as follows: look at Step 2, for example This step is taken

in a bid to retrieve the associated information for the IP source address

aaa.bbb.ccc.ddd belongs to Person X (from RB1), who is an executive (from RB2) In addition, for extracted field P, it is learnt that Pisa reserved port (from RB3) in an Operating System W (from RB4) environment

Following, a discussion on these steps:

Step 1: Obtain the extracted fields from the TCPIIP packet from Module 1; for

example, suppose the IP source address is aaa.bbb.ccc.ddd and the TCP source port is P

Step 2: Retrieve the associated information for the current extracted fields (from

the TCPIIP packet) from the RB, for exarnple, IP source address

aaa.bbb.ccc.ddd belongs to Person X Person X is found to be an

Real-time Risk Analysis on the Internet: a prototype

executive in the RB In addition, TCP source port P is found to be a reserved port Port P is also found to be a port normally used inside an Operating System W environment

25

Step 3: Link this information (Person X, P) to the KB Executives, for example,

incur a high level ofrisk (typically because they enjoy greater access rights

to more sensitive information) Reserved ports carry a medium level of risk and Operating System W environments carry a low level of risk Step 4: Use a consolidation method to determine risk values for ali the extracted

fields from the TCPIIP packet, for example, the risk level for Person X at

IP address aaa.bbb.ccc.ddd is 9 (out of 10, for instance) In addition, the risk level for port P as a reserved port is 7 and, as a standard port in an Operating System W environment, it is 2

Step 5: Consolidate ali the risk values determined in Step 4 into IRVs

Step 6: Consolidate ali the IRVs determined in Step 5 into a GRV, for example, a

GRV of 7 (for a scale out of 1 O) bas been determined by means of a certain consolidation method

Step 7: Retrieve the countermeasure information from the risk level activation

RB A GRV of7, for example, implies that the GRV falis into the Higb GRVrange

Step 8: Link the information from the RB to the countermeasure activation KB

The countermeasure value ofHigb GRV in the RB, for example, implies that a private key encryption countermeasure in the KB must be applied

to the current session from that point onwards

Step 9: Compile a list of countermeasures tobe executed (those found in Step 8)

and encapsulate them together with the original TCPIIP packet (The term

encapsulation is used in a different sense than usual here, though

Normaliy, the term encapsulation pertains to the idea that a packet is

"wrapped" with another packet, so that the original packet is

invisible/inaccessible and is usuatly used when a network protocol does not ''understand" the packet format [COME 97] In terms ofthe Internet, another header is ''wrapped around" the original packet This header can then only be removed ( decapsulated) by a protocol that "knows" how the packet bas been encapsulated The purpose of encapsulation is to enhance the security of that specific packet What is meant by the term

encapsulation in Step 9, is, however, something different The

encapsulation ofthe TCPIIP packet and the countermeasures means that it

is simply concatenated into an argument The purpose ofthis simply is to keep the data together when the packet and the countermeasures are passed

by argument to CE.)

Note that the entire foregoing process is based onan outgoing packet (a packet traveliing from Network 1 to Network 2) The process, however, remains the same for an incoming packet (a packet traveliing from Network 2 to Network 1)

3.3 Module 3 - the route finder

The purpose of Module 3 is to re-route the original TCPIIP packet according to the countermeasures determined in Module 2 The outputs of Module 3 wili be the specific route that the current TCPIIP packet must foliow (Refer to fig 3.3 for a reminder as to where the route finder fits into the prototype.)

26 lnformation Security Management & Small Systems Security

There are two kinds of possible outputs to be mentioned here The first possibility is that if the GRV were so low that no countermeasure needed to be executed on the TCPIIP packet, the output would simply be the original TCPIIP packet In this case, the original TCPIIP packet would simply be forwarded to the destination IP address The second possibility is that if some countermeasure(s) needed tobe executed on the TCPIIP packet, the encapsulated argument would first

be passed to the Countermeasure Executor (CE) At the CE, the encapsulated argument would then be taken apart and the compiled countermeasure(s) would be detected and executed on the accompanied TCPIIP packet The processed packet would then be passed back to GW Only then would the processed packet be forwarded to the destination IP address

Secondly, the fact that RtRA is done in real time not only makes life easier but also speeds up the process Much time is saved, as no explicit encryption or countermeasure bas to be executed on the data by the user him-/herself Most importantly, however, the real-time effect of RtRA actually provides the key to all the foregoing benefits tobe derived.from RtRA

Thirdly, the users and the workstations in a network do not need to know anything about RtRA, except that it is there and that it secures their data much more effectively than any conventional network-security system

There are, however, a few aspects in the realm of RtRA that stiH warrant further research One such aspect is the fact that RtRA should be able to deal with multiple connections, which the prototype cannot cope with at this stage Another aspect is that the prototype should be able to deal with asynchronous communication too Further research on implementing asynchronous RtRA communications is, therefore, sorely needed In addition, some optimisation issues might be addressed when applying the countermeasures Currently, for example, the risk analyser determines a GRV for every single packet and applies the countermeasures to every packet, with the result that it only follows the packet-level approach discussed under paragraph 2.2 The ability to incorporate both approaches is, therefore, stiH a shortcoming in the prototype By following both approaches, the prototype and the efficiency of RtRA will be enhanced even further Another hot spot for which further research is sorely needed is the refming and implementation of more effective countermeasures Countermeasures such as digital certificates and the distribution ofkeys also are possible areas that need tobe investigated The RB and

KB constitute yet another area that warrants further research Should ways and means be found to endow the process with the intelligence dynamically to grow,

Rea/-time Risk Analysis on the Internet: a prototype 27

new rules could be generated automatically as risk values change This would, in

turn, have the effect that the RB and KB would not be "read-only" any more and that the system administrator's job would be minimised in maintaining the RB and

KB

Be that as it may, RtRA is expected to have a significant impact on future technologies Some of the security problems that stand to be minimised include hacking (for instance, eavesdropping and message interception), as well as the encryption of the necessary data The only question left is this: the theory behind RtRA proved that it could work, but would it work in practice? The prototype attempted to prove the latter It is now up to researchers, system analysts and programmers to let RtRA come into its own and actually make its potentially significant contribution to the domain ofnetwork security

[COME 97] COMER, D.E.; 1997; Computer Networks and Internets; "Encapsulation"; ISBN

0-13-239070-1; New Jersey: Prentice Hali; p 230

[DERU 97] DE RU, W.G.; ELOFF, J.H.P.; November 1997; Computers and Security;

"Risk-analysis modelling with the use offuzzy logic"; Voi 15 no 3; pp 239-248 [EAGL 98] RAPTOR SYSTEMS; 1998; Technical White Paper: The Eagle 5.0 Firewall;

"Overview ofEagle 5.0 Features"; http://www.raptor.com

[FIRI 99] CHECKPOINT SOFTWARE TECHNOLOGIES LIMITED; 1999; Firewall-1;

www checkpoint.com

[FORD 97] FORD, W.; BAUM, M.S.; 1997; Secure Electronic Commerce; "Packet

Encryption"; ISBN 0-13-476342-4; Prentice Hill; pp 149-150

[FWTK 99] TRUSTED INFORMATION SYSTEMS INCORPORATED; 1999; Firewall

Toolkit; www.tis.com

[IBMC 97) IBM CONSULTING GROUP; 1997; IBM Firewall Version 3.2for AIX ata

Glance; "What is a firewall?"; International Business Machines Corporation; Second edition; pp 5-7; http://www.computerps.com/internet/security/firewalls/ [INTE 98) INTERNIC; 20 March 1998; Internic 15 Minute Series; "What is a Packet?";

http://krikkit.tss.nwu.edu/dss/traininglinternic/

[LABU 98] LABUSCHAGNE, L.; ELOFF, J.H.P.; 1998; Computers and Security; "The Use

of RtRA to Enable Dynamic Activation of Countermeasures"; Voi 17 no 4;

pp 347-357

[PABR 96) PABRAI, U.O.; GURBANI V.K.; 1996; Internet & TCPIIP Network Security,

"TCP/IP and Security"; ISBN 0-07-048215-2; McGraw-Hill; pp 69-74

[PFLE 89] PFLEEGER, C.P.; 1989; Security in Computing; ISBN 0-13-799016-2; pp 3-4 [PRIC 98) PRICE, K.; 1998; Intrusion Detection; "Characteristics of a Good Intrusion

Detection System"; http://www.cs.purdue.edu/coast/intrusion-detection/

[RAPT 98] AXENT TECHNOLOGIES; 1998; Raptor Firewal/; "Raptor Firewa115.0 White

Paper''; http://www.axent.com/product/rsbulfirewall4nt/default.htm

[RF AQ 98) RAPTOR SYSTEMS; 1998; Rap tor Firewall 5 O Frequently Asked Questions

(F AQ); "What is the Raptor Firewall 5.0 for Solaris?";

http://www.raptor.com/products/solaris5/s50faq.html

A practical approach to manage data communication security

first author and point of contact:

Key words: Data communication, Network security, Security management, Security

classification, IT Audit, EDP Audit, Availability, lntegrity, Confidentiality Abstract: This paper describes a practica} approach to manage the security of data

communication infrastructures The approach is based upon the classification ofnetwork segments and the description ofthe relation between segments This will result in a clear view of the security characteristics of ali relevant data communication paths, even in large networks This view is useful for data communication product managers, infonnation system owners and IT auditors The examples in this paper are based upon an implementation ofthis approach for the Rabobank IP network infrastructure The examples however reflect a simplified version ofthis network for illustration purposes

J H P Eloff et al (eds.), Information Security Management & Small Systems Security

© Springer Science+Business Media New York 1999

30 lnformation Security Management & Small Systems Security

The network infrastructure is an essential component in the security of computer applications The entire data communication path between users and the application, as well as the data communication path between application components, is relevant for the integrity and the confidentiality

of the information flows and the availability of the application

Due to the complexity of networks, application owners usually don't ha ve

a clear picture of the security characteristics of the data communication paths that are relevant for their application Furthermore, network infrastructure owners usually don't know the full range of information flows that pass through the sections they are responsible for Hence they both don't have a clear view of the security measures that should be implemented in this infrastructure, given the nature of the applications using the infrastructure However, traditional risk analysis (for example CRAMM [CCTA]) requires accurate information on the relation between business processes and information systems on the one hand, and between information systems and the underlying objects on the other hand As this information generally cannot be made available in a complex network situation, neither application nor infrastructure owners know whether and what additional measures should be implemented in either the application or the infrastructure A widely used alternative for complex networks is to implement the security measures which are necessary to comply to a certain baseline (for example the standard BS7799, Code of Practice [COP]) This only works however if every relevant section of the network complies to the baseline completely, and if the applications using the infrastructure do not require additional security measures In practice these conditions generally will not be met Hence the baseline approach isn't adequate either

As a result of the above, organisations probably implement security structures with gaps At the same time they may implement measures that are not necessary or not effective, due to other parts of the infrastructure that are less secure All in all this results in a security structure which is inadequate and unnecessary expensive

A solution to the above problem can be found by evaluating the implemented security measures in the infrastructure and subsequently classifying the various parts of the network By relating the security classification of the relevant parts of the network to the security classification of applications, one can fill the missing link between on the

A practica/ approach to manage data communication security 31 one hand security needs of applications and business processes and on the other hand security measures in the infrastructure This paper describes a practica! approach to implement such a solution

2 DEFINING THE CLASSIFICATION LEVELS

To identify whether a certain data communication path in a network infrastructure meets the security requirements for a specific application, one has to figure out which part of the infrastructure is used by the application If that relation is known, one can assess whether the security measures of the infrastructure cover the relevant security requirements sufficiently Because different applications use different parts of the infrastructure, the relation between application and parts of infrastructure generally cannot be done on a one to one hasis

A suitable segmentation of the network infrastructure however, can be used as an intermediate to make the above relation manageable To achieve this, the network infrastructure is divided into segments which on the one hand offer a certain security level with respect to the quality aspects availability, integrity and confidentiality, and on the other hand is within the area of responsibility of only one organisational unit If a certain minimal security level is applicable all over the given segment, then one can assign a corresponding classification level to the segment [ECC91] and [NCSC85] describe security classification standards for computer systems A similar way of classification can be used for classifying segments of a network infrastructure One can choose for a classification scheme which is specific for the organisation, or a classification scheme which can become a known standard, analogous to ITSEC and TCSEC In this paper we don't aim for a standard classification Hence we focus on relating different segments of the network infrastructure within one (large) organisation to the applications used within the same organisation Therefore we consider an Information Security Classification which is specific for the organisation Further research can focus on a standard classification which enables comparison of measures in general

The Information Security Classification is on the one hand used by application and business process owners to describe their needs On the other hand this classification has to be used with respect to the network infrastructure This can be done by relating the Information Security Classification to generic data communication goals that uniquely correspond