1. ©1999 Addison Wesley Longman Slide 13.1 Information System Security and Control 13

2. ©1999 Addison Wesley Longman Slide 13.2 Table 13.1 London Ambulance Service: an Information System Disaster

3. ©1999 Addison Wesley Longman Slide 13.3 Table 13.1 London 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

4. ©1999 Addison Wesley Longman Slide 13.4 Table 13.1 London Ambulance Service: an Information System Disaster PRODUCT Location of next pickup, selected to minimize delays and communicated immediately

5. ©1999 Addison Wesley Longman Slide 13.5 Table 13.1 London 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

6. ©1999 Addison Wesley Longman Slide 13.6 Table 13.1 London 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 transmitters and receivers Computer program making dispatching decisions

7. ©1999 Addison Wesley Longman Slide 13.7 Table 13.2 Common 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.

8. ©1999 Addison Wesley Longman Slide 13.8 Figure 13.1 Seven types of risks related to accidents

9. ©1999 Addison Wesley Longman Slide 13.9 Figure 13.2 Threats related to computer crime

10. ©1999 Addison Wesley Longman Slide 13.10 Box 13.1 Examples of fraud committed using transaction processing systems FORGERY IMPERSONATION FRAUD DISBURSEMENTS FRAUD INVENTORY FRAUD PAYROLL FRAUD PENSION FRAUD CASHIER FRAUD

11. ©1999 Addison Wesley Longman Slide 13.11 Figure 13.3 Check forgery

12. ©1999 Addison Wesley Longman Slide 13.12 Table 13.3 Conditions 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

13. ©1999 Addison Wesley Longman Slide 13.13 Figure 13.4 Value chain for system security and control

14. ©1999 Addison Wesley Longman Slide 13.14 Figure 13.5 Software change control

15. ©1999 Addison Wesley Longman Slide 13.15 Table 13.4 Controlling 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 PRIVILEGES What you know Password Special personal data What you have ID card Key to physical facility Where you are Call-back system Who 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

16. ©1999 Addison Wesley Longman Slide 13.16 Figure 13.7 Possible locations for checking data transfers in a corporate network

17. ©1999 Addison Wesley Longman Slide 13.17 Figure 13.8 Using public key encryption

18. ©1999 Addison Wesley Longman Slide 13.18 Figure 13.9 Validation checks for a course enrollment transaction