when controls don’t work: 4 unhappy information security scenarios

Narration Copyright 2003, The Trustees of Norwich University. Slide content Copyright 2003, Stephen Cobb.

When Production Controls Don’t Work: 4 Unhappy Scenarios

Stephen Cobb, CISSP

Author: Privacy for Business: Web sites & EmailContributing Author: Computer Security Handbook, 5th Edition

MSIANorwich University

of 10Copyright 2003-2010, Stephen Cobb.

4 Unhappy Scenarios

Rogue operations– Ziff Davis Media

Maintenance problems– Western Union

Failure to apply controls– Eli Lilly

Compound problems– London Ambulance Service


Rogue Operations: Ziff Davis Media

Company uses outside services for secure website operations

Marketing folks decided to run a promotion via the website

They bypass the process in place to ensure changes to website don’t affect security

Web server accumulated names, addresses, and some credit cards, in an unprotected text file

Result was lawsuits and fines


Maintenance Problems: Western Union

The Western Union Money Transfer Service at westernunion.com lets you send cash to almost anywhere in the world. Send money to a loved one in the U.S. and over 150 other countries – Quote from website

I sent money to my daughter, using my credit card Got a call some months later advising me to cancel card because it was

“possibly compromised” Hacker had been probing site during a maintenance cycle which had

altered permissions on site, presumably for convenience, found the credit card file

Impact: no fines, but stock price took a hit, as did customer confidence (guess who has not used them since)

Note that the web site now says NOTHING about security


Failure to Apply Controls: Lilly

The Eli Lilly Prozac Email Snafu Programmer hand-coded application to send same

message to 700 people One character in code was in the wrong place Result: email addresses of all recipients appeared

in “To” instead of remaining hidden in “BCC” Many mainframe-oriented production controls in

place at Lilly, but not followed by website Inadequate testing and no peer or management

review of code


Compound Problems: LAS CAD Disaster

London Ambulance System (LAS) covers 600 sq. miles The only ambulance service for 6.8 million people In 1992, there were 2,700 staff and 750 ambulances 2,000-2,500 calls received every day by dispatch New Computer Aided Dispatch (CAD) system introduced Taking emergency calls, accepting incident details Determining which ambulance to send and communicating

details of the incident to the ambulance dispatched. On November 4th, the system crashed and rebooting the

system did not help, calls in the computer were lost Some ambulances arrived too late to help the victims


LAS CAD Disaster: The Reasons

Company that won the bid was $1 million cheaper than the next lowest bidder

Reason for the large margin was not questioned The system elements were tested, but no test done on the

fully integrated system Company did not adequately stress test the system under

simulated conditions Problems found by testing system elements were not fixed Backup file servers were not tested, and not fully configured

by time system went live Potentially dangerous problems were overlooked



The system was fully implemented before full confidence in the reliability,

accuracy, and quickness of the system was achieved

The system crash was caused by a memory leak, a programming error resulting

from carelessness and lack of quality assurance of program code changes

“What is clear from the Inquiry Team's investigations is that neither the CAD

system itself, nor its users, were ready for full implementation…the CAD

software was not complete, not properly tuned, and not fully tested…

“The resilience of the hardware under a full load had not been tested. The fall-

back option to the second file server had certainly not been tested…

“There were outstanding problems with data transmission to and from the

mobile data terminals.…Staff, both within Central Ambulance Control (CAC)

and ambulance crews, had no confidence in the system and was not all fully

trained and there was no paper backup…



“There had been no attempt to foresee fully the effect of inaccurate or incomplete data available to the system (late status of reporting/vehicle locations etc.)…

“These imperfections led to an increase in the number of exception messages that would have to be dealt with and which in turn would lead to more call-backs and enquiries. In particular the decision on that day to use only the computer generated resource allocations (which were proven to be less than 100% reliable) was a high-risk move.”

Software for the system was written in Visual Basic and was run in a Windows operating system (“a fundamental flaw in the design”).

“The result was an interface that was so slow in operation that users attempted to speed up the system by opening every application they would need at the start of their shift, and then using the Windows multi-tasking environment to move between them as required. This highly memory-intensive method of working would have had the effect of reducing system performance still further.”


Thank You!

Note: This is a set of slides from an Information Assurance course I helped create in 2003

Part of award-winning Master of Science program (MSIA) at Norwich University, Vermont– http://infoassurance.norwich.edu

Content remains accurate (but may appear dated) Lessons learned still apply Stephen Cobb, CISSP

– www.cobbsblog.com– www.linkedin.com/in/stephencobb

when controls don’t work: 4 unhappy information security scenarios

Technology