©1999 Addison Wesley Longman Slide 13.1

InformationSystem Securityand Control

13

©1999 Addison Wesley Longman Slide 13.2

Table 13.1London Ambulance Service: an Information System Disaster

©1999 Addison Wesley Longman Slide 13.3

Table 13.1London Ambulance Service: an Information System Disaster

CUSTOMER

People requiring emergency medical care

Ambulance drivers requiring information about where to pick up patients requiring emergency transportation to a hospital

©1999 Addison Wesley Longman Slide 13.4

Table 13.1London Ambulance Service: an Information System Disaster

PRODUCT

Location of next pickup, selected to minimize

delays and communicated immediately

©1999 Addison Wesley Longman Slide 13.5

Table 13.1London Ambulance Service: an Information System Disaster

BUSINESS PROCESS

Major steps:•Track the location of all ambulances•Receive telephone notification of an emergency situation requiring an ambulance•Decide which ambulance should respond to the emergency•Notify the ambulance driver•Track the disposition of each call

Rationale:

Treat all of London as a single zone

Automate many of the dispatching decisions

©1999 Addison Wesley Longman Slide 13.6

Table 13.1London Ambulance Service: an Information System Disaster

PARTICIPANTS

Dispatching staff

Ambulance drivers

INFORMATION

Location of people having medical emergencies

Location of ambulances

Geography of London

TECHNOLOGY

Telephone

Radio transmittersand receivers

Computer program making dispatching decisions

©1999 Addison Wesley Longman Slide 13.7

Table 13.2Common Reasons for Project Failure at Different Project Phases

INITIATION•The reasons for building the system have too little support.•The system seems too expensive.

DEVELOPMENT•It is too difficult to define the requirements.•The system is not technically feasible.•The project is too difficult is too difficult for technical staff assigned.

IMPLEMENTATION•The system requires too great a change from existing work practices.•Potential users dislike the system or resist using it.•Too little effort is put into the implementation.

OPERATION AND MAINTENANCE•System controls are insufficient.•Too little effort goes into supporting effective use.•The system is not updated as business needs change.

©1999 Addison Wesley Longman Slide 13.8

Figure 13.1Seven types of risks related to accidents

©1999 Addison Wesley Longman Slide 13.9

Figure 13.2Threats related to computer crime

©1999 Addison Wesley Longman Slide 13.10

Box 13.1Examples of fraud committed using transaction processing systems

•FORGERY

•IMPERSONATION FRAUD

•DISBURSEMENTS FRAUD

•INVENTORY FRAUD

•PAYROLL FRAUD

•PENSION FRAUD

•CASHIER FRAUD

©1999 Addison Wesley Longman Slide 13.11

Figure 13.3Check forgery

©1999 Addison Wesley Longman Slide 13.12

Table 13.3Conditions That Increase Vulnerability

THREATS FROM UNINTENTIONAL OCCURRENCES•Operator error

•Hardware malfunction

•Software bugs

•Data errors

•Damage to physical facilities

•Inadequate system performance

•Liability

THREATS FROM INTENTIONAL ACTIONS•Theft

•Vandalism and sabotage

©1999 Addison Wesley Longman Slide 13.13

Figure 13.4Value chain for system security and control

©1999 Addison Wesley Longman Slide 13.14

Figure 13.5Software change control

©1999 Addison Wesley Longman Slide 13.15

Table 13.4Controlling Access to Data, Computers, and Networks

ENFORCE MANUAL DATA HANDLING GUIDELINES•Lock desks•Shred discarded documents and manuals

DEFINE ACCESS PRIVILEGES•Give different individuals different levels of privilege for using the computer•Give different individuals different levels of access to specific data files

ENFORCE ACCESS PRIVILEGESWhat you know•Password•Special personal dataWhat you have•ID card•Key to physical facilityWhere you are•Call-back systemWho you are•Fingerprint or handprint or handprint•Retina pattern•Voice pattern

CONTROL INCOMING DATA NETWORKS AND OTHER MEDIA•Use firewalls•Scan for viruses

MAKE DATA MEANINGLESS TO ANYONE LACKING AUTHORIZATION•Data encryption

©1999 Addison Wesley Longman Slide 13.16

Figure 13.7Possible locations for checking data transfers in a corporate network

©1999 Addison Wesley Longman Slide 13.17

Figure 13.8Using public key encryption

©1999 Addison Wesley Longman Slide 13.18

Figure 13.9Validation checks for a course enrollment transaction