Con-ipufer Fraud & Security Bfflfefin January 1993

tools is based on Hoskyns’ own risk assessment

methodology. Users work through an automated

questionnaire, and the tool then focuses on the ten highest risks. Project Risk costs f 2950 + VAT

for the first copy and f950 + VAT for any

subsequent copies purchases. Users can join the

client support programme (CSP) for f200 per

annum. CSP members have access to a

technical Helpdesk and are entitled to product

upgrades. For more information contact Teresa

Stapleton on +44 (0)71 735 0800.

Graphnet Computers Ltd have been

appointed as agents for V-Buster, an anti-virus

program. It claims to be able to detect 1494

‘known’ viruses, as well as the self mutating

viruses. It consists of a number of programs,

which include facilities to repair and rebuild,

damaged boot sector, partition tables and files. It

is written entirely in assembly language. It has

already been used widely in Australia and the Far

East, where it claims Intel, Motorola and National

Semiconductor amongst its users. V-Buster is

available in a standalone version for f99 + VAT,

and as a network version for f799 + VAT.

Registered users are eligible for upgrades at a

reduced price. For more details contact Rebecca

on +44 (0)278 663680.

C & A Systems Security has announced the

launch of a PC-based security management. PC

Consultant will self install on a PC and, via a

series of question modules, will assess the

security in place. All recommendation reports are

justified “in business terms”. PC Consultant can

be used on any IBM compatible running

MS-DOS, PC-DOS at level 3.1 or higher. No price

is listed. For more information contact Steve

Addison on +44 (0)625 503205.

The virus test centre at the University of

Hamburg has released the results of a series of

tests of popular anti-virus packages against self

mutating viruses. The tests involved seven

mutation viruses: CoffeeShop, CryptLab,

Dedicated, Fear, Groove, Pogue and Questo;

from each of which around 2000 replications were

generated. The results were:

IBM Virscan 2.2.3A

Dr Solomon’s ~6.01

Untouchable UTScan Central Point

Norton ~2.1

McAfee v97

100% reliable

100% reliable

75% reliable 25% reliable

0% reliable

0% reliable

Fortunately there are currently very few examples of mutation based viruses ‘in the wild’.

EDI SECURITY

Risks and Solutions

Peter Kenny SD-Scicon, UK

Until recently, relatively little attention has

been paid to the security aspects of EDI. However the advent of EDI payments services,

and the increasing reliance by many

organizations on their EDI systems to provide

strategic external communications, have led to

the acceptance that security is an important aspect of EDI which must be addressed urgently.

This paper starts by outlining the manner in which EDI is being used to provide banking

services. It then describes the perceived threats

to the security of EDI-based trading, with

particular reference to banking EDI, and outlines the EDIFACT security standards which are being

developed to help counter these threats. Finally

it summarises the implementation issues which

must be handled in practice by secure EDI systems.

Introduction to EDI in banking

Diagram 1 shows a simple EDI banking

scenario for Figure 1 ‘Open Account’ payments.

The buyer sends a Purchase Order to the seller

and subsequently receives the goods ordered

and an EDI Invoice message. On the agreed date

he sends a Payment Order message to his bank,

together with a Remittance Advice message. At

6 01993 Elsevier Science Publishers Ltd

January 1993 Computer Fraud & Security Bulletin

the appropriate time the buyer’s bank sends a

FINPAY EDI message to the seller’s bank,

requesting the latter to credit the seller’s bank

account and providing the original remittance

advice information. The buyer’s bank also sends

an appropriate Debit Advice message to the

buyer. When the seller’s bank receives the

FINPAY message, it credits the seller’s account

and forwards a Credit Advice message to the

seller, together with the Remittance Advice

information (allowing the seller to reconcile his

received payments with his invoices).

Communication between the parties would

typically be handled as follows:

- messages between the buyer and seller

would be exchanged via a store-and-forward VADS network;

- messages between the buyer/seller and their

banks would also be exchanged via a VADS

network;

- messages between the banks would be exchanged via an X.25 packet network for intra-national transfers and via SWIFT for international transfers.

In practice there are many possiblevariations

from this relatively simple model and many more

banking applications for EDI are currently being

planned by standardization committees across

the world. These applications include the

provision of support for the following:

l Bills of Exchange

l Letters of Credit

l Statements

l Standing Orders

l Direct Debits

l Factoring.

Security threats

Even a cursory examination of the Open Account payment scenario described above

reveals that there are many points in an EDI

system where security could be breached

(accidentally or by design) with consequent loss of information, orders, customer confidence,

money, etc. In this section we examine some of

the important security threats which are specific

to the EDI environment. General security issues (database backups, media control, physical protection, application auditing, etc.) are not

PURCHASE ORDER

BUYER SELLER

+ INVOICE

A A

PAYMENT DEBIT CREDIT

OmEK ADVICE ADVICE

AND ANJJ

REMITrANc!s REMITTANCE

ADVICE

f

ADVICE

BUYER’ S INTER-BANK EDI TRXNSFE~~ (FINPAY) SELLER ’ 3

Figure 1: ‘Open Account’ EDI Payment.

01993 Elsevier Science Publishers Ltd 7

Computer Fraud & Security Bulletin January 1993

covered in this paper; nor is any attempt made to give a comprehensive description of all EDI

security threats -the primary objective is to give a flavour of the types of threat by outlining some

typical examples.

Masquerade

An attacker could masquerade as a genuine

buyer to submit a Payment Order which transfers

funds to the bank account of a dummy seller created by himself. An employee of the buyer

could masquerade as an authorized user of the

buyer’s EDI system to initiate payments to a dummy seller company created by himself.

Alternatively he could modifythe account number and name associated on file with a genuine seller

in order to route payments to his own bank account. An attacker could masquerade as a

genuine buyer to mislead a seller by issuing a fraudulent Purchase Order.

Data Modification

A genuine message between EDI partners

could be modified or destroyed, accidentally or in

order to mislead the recipient. The modification or destruction could occur in many different places, including: at the sender’s or recipient’s EDI system: within the VADS data centre; within

the network operated by the VADS provider.

Message Replay

An EDI message could be transferred twice

due to a number of causes, including: software

faults at the VADS data centre or the sender’s

EDI system; incorrect recovery following a network failure; fraudulent playback of the

message following recording of the message while it was in transit across the network.

Repudiation

Either party could deny that they sent or received a particular message. For example, a buyer might mistakenly issue a Payment Order to

a bank and later deny that the message was sent,

in orderto cover up the original error. Alternatively a bank might lose a Payment Order and then

deny that it was ever received, potentially costing

the buyer penalty charges for late payment.

Denial of Service

Delay in delivery of a message could cause a wide range of problems. For example, a Payment Order from a buyer could be delayed

within the network beyond the bank processing

deadline and cause a large amount of overnight

interest to be lost.

Loss of Confidentiality

If a competitor could gain access to the

contents of messages they would be able to obtain commercially sensitive information such

as pricing, discount levels, customer lists,

business levels, etc. The message contents

could be accessed by monitoring network transmissions or by examining files at the sites of

the buyer, seller, bank or VADS data centre.

EDIFACT security standardization

In order to combat the security threats described above, EDI security activities have

been underway for some years in many bodies concerned with EDI standardization. There is now emerging a set of recommendations for message level security from the UN/EDIFACT

Security Joint Working Group [reference l] which

is outlined below.

The security recommendations essentially

define how the techniques B are to be utilized in order to provide the following security functions:

l message’s sequence integrity

l message content integrity

. message origin authentication

l non-repudiation of origin

l confidentiality of content

l non-repudiation of receipt.

8 01993 Elsevier Science Publishers Ltd

January 1993 Computer Fraud & Security Bulletin

The approach adopted by the

recommendations is based on the use of pairs of

security headers and trailers. A security header is defined as an EDIFACT segment (SEC),

positioned just after the message header; it specifies the security methods applied to the

message and holds the associated data necessary to perform validation of the message.

A security trailer is also defined as an EDIFACT

segment (RES), positioned just before the message trailer; it holds the security result corresponding to the security services specified

in the associated security header. In addition the recommendations define a message (FUNACK) the objectives of which include non-repudiatable message receipt acknowledgement.

Security implementation

It is important to recognize that the EDIFACT

Security Recommendations described above are

concerned primarily with the formats of security

segments and messages exchanged between EDI partners and not with security implementation. An actual implementation of EDI

security needs to be concerned with many practical issues, including the following:

control of access to the EDI system

(passwords, smartcards, smart-diskettes, etc.);

secure storage of private keys;

user control over digital signature production

and verification;

public key certification;

secure audit trail and archiving of signed

messages;

physical security of EDI system;

viruses and trojan horses;

application security;

. network security (service integrity, access

control, service levels, audit trails, etc.).

Reference

Recommendations for UN/EDIFACT

message level security from the UN/EDIFACT

Security J WG.

0 Copyright 1992 SD-Scicon UK Limited

EDI Security in Practice

C.J. Clark

Clark Consultants,

Over the last 30 years computers have

increasingly been used within industrial

companies, financial institutions and public

administrations for a wide variety of internal

applications. Since the early 1980s there has

been a growing realisation in many sectors that

significant business benefits can be achieved by

extending the boundaries of these systems to

incorporate external trading partners. The

developments in telecommunications, in

international data standards and the widespread

availability of PCs have enabled large numbers

of organizations to implement EDI both on a

national and international basis. In addition to the

communication of structured messages based

upon national standards such as TRADACOMS

and international standards such as

UN/EDIFACT, many organizations are also using

less structured forms of communication based on

text messaging systems linked into their in-house

office systems. Many of these operations started

as trial operations involving afewtrading partners

where security considerations were secondary to

achieving the connection. As a greater proportion

of routine business transactions come to rely on

electronicforms of communication the realization

is growing that more emphasis needs to be given

to the security aspects of EDI. However in a

commercial environment security has to be

balanced against risk and the cost and

practicality of any security procedures justified.

01993 Elsevier Science Publishers Ltd 9