THE C O M P U T E R LAW AND SECURITY REPORT 3 CLSR

reliance on particular applications is rarely quantified either by the user himself or by the company as a whole. Guidelines may be in place but standards are not. By its nature a guideline, as its name suggests, is only intended to provide an alternative or simple procedure. It is a very grey word that says you may do this or that. On the other hand you may wish to try something completely different. Guidelines are very limiting and leave a great deal to individual interpretation. When something goes wrong the "get out" is that the guideline that should have been followed did not state its intentions clearly and therefore we decided to take an option that we thought would resolve the problem even though it was not stated. Guidelines are also impossible to police because one would have to investigate thoroughly every sideways step from the supposedly straight path. In addition, guidelines provide little in the way of support should strong disciplinary procedures need to be involved as the defence will be that the guideline was only a guideline and did not state a definite fact. The creation of standards dismisses many of the areas of controversy outlined above. A standard is a standard is a standard. There is no grey area and no overstepping the line which the standard is intended for. The standard is policy - policy that has been discussed and agreed upon by responsible management and staff throughout the company. It is a policy that carries significant weight if not adhered to. Investigative and disciplinary procedures are agreed and acted upon if the standard is abused at any time by any person no matter what their position or authority. Investigation is simplified because the culprit has to justify his reasons for going against laid down and publicised corporate policy. If the misdemeanour was carried out with malicious intent the rule breaker will find it difficult to come up with a plausible excuse for his actions and the punishment that follows will already be clearly defined. The provision of standards gives an added strength to the company and for this reason a standard should never be bent, otherwise its authority is gone forever. Clearly, individual cases have to be judged on their merits. However, once a precedent is set it becomes difficult to implement the correct procedures in future cases. In addition, in a case of fraudulent activity that is taken to a court of law, if the defendant can prove that others have committed such crimes and not been punished by the employer, the plaintiff's case could well be weakened or in fact thrown out. In such an instance it is the employer who will lose more face than the supposedly dishonest employee. In developing computer security standards the computer department will have a major role to play as they will be setting the technical boundaries that can be used on given hardware and software and they will of course have to ensure successful implementation and policing. The actual standard of security and its depth and area of cover needs to be decided by the user management and not the D.R division. Each user will have his own requirements and what is acceptable to one may be wholly unacceptable or even unnecessary to another. To this end the D.R security officer will provide the board and the dice but the users set the rules of the game. The integl;ity of information is vital in many organisations and modern computer networking makes the opportunity to abuse relatively easier. Information can be gained by a larger number of people who do not in fact ever need to be physically in the same building in which the information is centralised. Internal and external threats are increasing all the time as is the

technology which can be used to overcome lax and even fairly strict security systems. Standards will not necessarily prevent such intrusions but they will go a long way in building up protection and providing a means on which to base investigations. The adoption of corporate standards can be a hard task as the philosphy behind them can be alien to some company management. Selling the concept is not difficult as the many benefits that can be achieved are of minimal cost. Justification is obvious to any company that processes sentitive data. The concept needs to be sold too and have the absolute backing of all senior management within the organisation. Without their fundamental support standards will never be achieved or implemented with any sense of meaning. Therefore, if the creation of standards to protect your systems and general information is of concern to you the sales emphasis must be directed at the decision makers with authority and perception not the also rans who think that everything in the garden is rosy and that security classification and control is best left in the hands of the uniformed attendant at the main gate. In summary, guidelines are rarely worth the paper they are written on simply because they leave too much to the individual and seldom do they respect the corporate being. Standards, on the other hand, provide a foundation on which to build a security strategy that is backed up by defined and documented procedures. In essence they are the rules by which your company sets its security disciplines. They are rigid in their structure and do not leave any room for misunderstanding. In the next article of this series we will aim to help you identify the areas where standards can be of most use and value to your organisation.

Yvo Henniker-Heeton, Report Correspondent

A N A T O M Y OF A D ISASTER

The first in a series by David Davies

Introduction One of the most fascinating of human traits is their blase approach to possible disaster. Serious road accidents are something that happens to someone else, so drivers carry on taking appalling risks at high speed. In corporate terms management takes a similar approach to disaster and computer disasters are no exception. "It won't happen to us" or "We'd muddle through somehow" are common excuses for the absence of a disaster recovery plan. Psychologists tell us that this is because we cannot come to terms with something we have not previously experienced: we simply cannot imagine the experience, therefore it has no reality as something that could affect us. In this series I will be relaying the experiences of those people who have been involved in computer disasters, the lessons they have learned and the effects of the disaster on their company and on their own lives. If you are one of the great majority without a workable recovery plan, remember as you read: tomorrow this could be you! Company: Denis Ferranti Meters Ltd. Cause of disaster: Fire Date of dlsaster: October 1980 Source: Presentation by Elfyn Hughes, DPM at the time of the disaster, at NCC conference, 3/87 Company: Electrical & mechanical engineers, 600

employees.

13

SEPTEMBER - OCTOBER THE COMPUTER LAW AND SECURITY REPORT

Computer: ICL 2903, run in batch mode. Applications: Payroll, financial systems, sales & purchase ledger Resilience: Gentleman's agreement access to mirror image site 40 miles away Daily back ups of data to fireproof safe in same building Written disaster recovery plan based on the gentleman's agreement. The plan was tested on site but the tests never involved an invocation of the agreement. Disaster: A fire stated in the stores area on ground floor at 7.30pm on a Thursday. It swept through the ground floor, where the safe containing the back up data was kept. It spread to the first floor, destroying the computer installation and 80% of the current data. The intensity of the fire was such that the smell of burning plastic, from the store of plastic telephones, was apparent two miles away. Recovery of data: The fire safe was buried amongst the debris caused by the collapsed first floor, and could not be opened until the following Saturday. The heat had melted the brass fittings in the lock and it was necessary to remove the door. The back up disks and source programs appeared intact, but could not be used as all documentation had been lost. No documentation had been backed up. Resumption of computing functions: ICL agreed to provide a new configuration in 2 -3 days, and to copy the back up disks. However: 1. The "gentleman" with whom the company had an unwritten reciprocal agreement refused to honour the agreement. It would have taken between two and three days just to set up the system on their computer, and the company concerned was not prepared to tolerate the disruption. 2. The company was only insured for replacement by an identical machine, which limited the company's recovery options. It was decided to hire a replacement machine whilst a decision was made. It took the insurers twelve days to agree to this. it took three weeks to find alternative accommodation; there was no capacity on the hired system to resume all computing functions and payroll was run in batch mode from Manchester. Manuals were rewritten from memory, as were stores records. The company was fortunate enough to have a stores clerk who recreated the order book entirely from a photographic memory. It was eventually decided to upgrade the system when it was replaced. Cost: The fire eventually cost the company £4,500,000, and, apart from the areas outlined, all its records. Lessons learned: 1. Get your plans all written down and then double what you expect to go wrong. 2. Reach a written agreement with the unions for wages payment in the event of a disaster: a fixed rate, paid late. Write the agreement into the disaster recovery plan. 3. DupliCate everything 4. Keep all documentation off site 5. Do not compromise on security 6. Check your insurance policies 7. Do not rely on unwritten or unenforceable agreements. Comments: Particularly by the standards of 1980, this company has done more than 95% of DP installations to ensure that it survived a disaster. It was let down in two classic areas: the usual gentleman's agreement that was not honoured when it was needed, and an insurance company whose policy restrictions created unnecessary complications, and whose slow response added unduly to the recovery time.

The company was fortunate in the responses and talents of its own staff, particularly the stores clerk with photographic memory. It also owes much to its own efforts. The simple mistakes that were made, particularly the absence of off site documentation, off site storage of the recovery plan and reliance on a gentleman's agreement, are typical of the sort of mistakes that companies make when they try to do it all themselves. They lacked an input from someone who has seen just what can go wrong. As they themselves said, "We had simply not envisaged the sheer scale of what would happen ."

David Davies

C O M P U T E R C R I M E - W H A T TO D O B E F O R E IT H A P P E N S

Presented to the INTEREX 87 Conference September 1987 Las Vegas, Nevada ABSTRACT: Many computer installations do not have any formal plans on what to do when it has been a victim of a computer abuse. The concept of the Computer Abuse Response Team is proposed, and ways of preserving evidence to make prosecution easier are presented.

I. introduction It's late. You are the data processing manager for a large east coast bank. You're watching the 11pm news when you get a call from your night operations supervisor, who says he believes that his staff has just aborted an unauthorized remote terminal session. What do you do? Or, the FBI walks in with the following printout:

Numb: 212 Sub: BANK SYSTEM From: THE SERPENT (76) To: ALL Date: 4/14/85 11:55:40 AM This number is to a BANK system, believe it's a DEC:

212-555-5000 LOGIN 1,4 pw: SECRET

USE AND ABUSE!!!!!~! The FBI informs you that the telephone number is to your bank, and it has been posted on a computer bulletin board for at least a month. Again, what do you do? These scenarios are happening more often than people want to admit. This paper discusses not so much how to prevent these situations, but rather what should be done when a problem is uncovered.

How much computer crime is them? Joseph O'Donoghue of the Department of Behavioural Science at Mercy College in Dobbs Ferry, New York, recently surveyed the chief executive officers of the Forbes 500 corporations concerning computer crime within their organization. 10'Donogue found that of the 184 respondents surveyed, 56 percent had experienced a computer abuse incident, and the average loss was $118,932. 2 Roughly 79 percent of the incidents were committed by individuals that had contact with the organizations employees, contractors, competitors, or customers. 3 While the dollar amount per incident is lower in O'Donoghue's report, it tends to support the American Bar Association's (ABA) 1984, report, "Report on Computer Crime." The ABA surveyed selected firms from Fortune magazine's list of the

14