Book Excerpt: The Adventures of an IT Leader, Part 3
A new CIO scrambles to contain a security breach—and to keep his job. Read the third installment of our exclusive series.
Wed, March 11, 2009
CIO — The story so far: Jim Barton, the head of loan operations for financial services company IVK, has been tapped as the CIO by the company's new CEO, Carl Williams. The previous CIO has been fired, and Barton must restore Williams's confidence in IT while he learns on the job. In his previous role, Barton had argued against a security upgrade. Now an apparent data breach may have compromised customer information, and Barton's job as CIO is on the line. Read the first and second installment.
Friday, June 29, 9:12 a.m....
Barton and his direct reports had convened at 7:15 a.m., and they'd begun talking through a list of issues.
First, they needed to identify the security measures they wanted to implement to reduce the risk of future attacks. The upgrade project that had been rejected earlier would be accelerated, but Barton wanted them to figure out what else they could do.
Second, they needed to decide what should be done to make the company secure against additional mischief from the attack that had just happened. They had no smoking gun to tell them that there had been intruders, but neither could anyone think of a way a database index file could be renamed without someone meaning to do it.
Third, they needed to figure out what to recommend to Williams about what, if anything, they needed to disclose outside the company. This was the issue most likely to get people fired, the issue most likely to spell an ugly end for IVK.
Friday, June 29, 3:47 p.m....
Options were shaping up. The team would work on "future event avoidance" on a less urgent time frame, but the other two issues, recovery from the attack and what to disclose, had to be dealt with now. There were three possible courses of action:
1. Do nothing. Assume that the past mischief was the worst that the bad guys had intended—if in fact there had been bad guys.
2. Shut down the company except for operations that could run manually and rebuild critical systems from development files. This was the "playing it as safe as possible" option, but the shutdown would be noticeable enough from outside IVK that it would need to be explained.
3. Build a mirror site from development files and rebuild production systems after the mirror site was up and running. It would cost money and take a couple of weeks to assemble the necessary facilities and equipment.
