It was the ultimate IS nightmare. In July 1996, a soon-to-be-fired 30-year-old network program designer at Omega Engineering Inc.'s Bridgeport, New Jersey, facility allegedly planted a LAN-based logic bomb, a program that eats through files or reformats hard drives, in the company's network. Several weeks later, the bomb wiped out Omega's software and left the manufacturer of high-tech measurement and control instruments with an estimated US$12 million in lost sales and repair costs, making it one of the most expensive computer sabotage cases ever investigated by the U.S. Secret Service. In January of this year, a federal grand jury indicted Timothy A. Lloyd of Wilmington, Del., on charges of planting the bomb.
Such vengeful, destructive acts by IS professionals toward their former employers are rare, but Omega's case highlights how vulnerable organisations are to them. IS workers, particularly those who administer and maintain networks, databases and other key systems, pose the biggest threat because of their high-level systems access and knowledge. So can you avoid the fate that befell Omega? "You can't stop a technologist from creating a logic bomb or a hole in your security systems," says John Puckett, assistant vice president of information technology at GTE Internetworking (formerly BBN Corp.) in Cambridge, Massachusetts. "All you can do is let him know of his responsibilities and what is acceptable behaviour for a person in a position of responsibility."But by taking a few basic precautions, CIOs can reduce the risk of IT sabotage.
Structuring your IS department so that responsibility for sensitive systems is shared, vigilantly adhering to security procedures and minimising animosity toward the company by dismissing employees as humanely as possible can protect you-and your systems.
Share the Load
For starters, no one person should have responsibility for managing security and have access to all of an organisation's critical systems. "Nobody should ever hold all of the keys to the kingdom," says Cris Castro, a principal with Ernst & Young LLP's information systems assurance and advisory service based in Palo Alto, California. Staff members who have responsibility for issuing network accounts and passwords, for example, should not be the people who audit those procedures and monitor compliance with security policies. Dividing these responsibilities between two or more people reduces the opportunity for individuals to make mischief.
Omega learned that lesson the hard way. Before he was let go, Lloyd was both the company's chief network program designer and its network administrator. In his dual role, Lloyd managed the network and was in charge of updating and backing up the company's databases and files. In effect, no one at Omega could match Lloyd's knowledge of the company's network or monitor his work.
Investigators charge that Lloyd anticipated his dismissal and planted the logic bomb before he was fired. About three weeks after Lloyd was canned, reportedly after a falling-out with his bosses, the bomb went off. Omega's network operating system deleted all of the company's design and production files. The incident crippled the company's network and brought business to a halt. Lloyd also allegedly stole all the backup tapes and replaced them with blanks.
"We'll never rely on one individual like that again," says Al DiFrancesco, Omega's director of human resources. Omega now divides Lloyd's former duties among several people and stores a set of backup tapes at a secure, offsite location.
One of the basic tenets of IS security is vigilant enforcement of systems access rules. This becomes especially important when a member of the IS department is let go. Foremost among the rules is keeping timely records of employees' accounts and passwords. In organisations with systems under the control of business units and with the growth of telecommuting and virtual organisations, keeping track of who has access to which systems can be a logistical headache. "Many organisations are out of control; they've lost knowledge of who has access to what," says Ron Tarro, senior manager of Ernst & Young's strategic advisory services based in Boca Raton, Florida. "If you fire somebody and you don't know what systems he has access to, that's a big problem." Unfortunately, Tarro says, that state of affairs is all too common.
It's wise to have a well thought-out, documented security policy outlining rules regarding systems and data access for the whole organisation. The policy can also establish clear grounds for dismissing an employee who doesn't respect security rules. For Internet service provider GTE Internetworking, for example, sound security and reliability are vital to the company's livelihood. Customers would desert GTE in droves if the company experienced a prolonged service outage for any reason, and they wouldn't have much sympathy if a logic bomb disrupted their e-commerce efforts or crashed their extranets.
To convey the company's commitment to high security standards, GTE Internetworking distributes a document to all employees that contains its IT security policy and states that failure to adhere to the policy could result in disciplinary measures or dismissal. The policy was reviewed by the company's executive management team and president, who sent a letter to all employees endorsing its measures. It states that employees should not try to access information to which they are not entitled, sharing passwords is forbidden, employees should not use technology for nonwork-related activity and no one should attempt to bypass security protocols.
"A lot of it is just common sense," Puckett says. But instating written policies endorsed by top-level executives tells employees that the organisation takes security very seriously, and no one can claim ignorance if caught violating the rules.
The risk of security breaches goes up after a dismissal, so CIOs have to be certain after an IS staffer is fired that everyone else in their organisation strictly adheres to all existing security policies. In addition, it's prudent to take extra precautions, particularly if the dismissed employee was a network administrator or a security specialist or held some other position in which he could potentially wreak havoc. For example, IS managers should try to assess the fired employee's frame of mind before the dismissal. Did he have a history of disciplinary problems? How did he react when he learned that his job was in jeopardy? Did he threaten to retaliate? If you suspect that he might, you should examine the employee's recent e-mail messages and work files. It might be a good idea to purge his most recent programming work from your systems if sabotage may be a real possibility.
Also consider issuing new passwords to your whole staff, particularly if the fired employee has the ability to hack into your network from the outside. "He might remember that his colleague Suzy used her dog's name for her password," says Mark Mercer, senior manager of Ernst & Young's national information security group based in Kansas City, Missouri. That might be all the opening a technically adept former staff member needs to break into your systems from the comfort of his home. As organisations use the Internet to provide remote access to their databases and networks, they open themselves to hacking from the outside. Former employees who know which firewall product you're using and other technical specs of your systems can do the most damage. So even if you've taken away his key card, a fired employee can still do harm. In addition, it's sometimes a good idea to inform business partners about the termination of a key staffer. A malicious person may look to your outsourcer or vendors for help in wreaking havoc on your systems. He might, for example, call a vendor or outsourcer and say he forgot his password to the network operating system and ask for the default password.
In addition to taking security precautions, IS managers can reduce the risk of retaliation by handling the firing of an employee in a direct but sensitive manner. It's rare to have to fire someone on the spot for a serious infraction.
What's more common is a dismissal as part of an organisational downsizing or when an employee isn't performing up to standards. Whatever the reason, when you let somebody go, make sure you are prepared to articulate clearly why you are taking that action, says Kavin Moody, executive in residence at The Centre for Information Management Studies at Babson College in Wellesley, Massachusetts, and a former IT executive at The Gillette Co. and BankBoston Corp. Remember, the employee may not fully comprehend the situation, even if he knew it was a possibility. "You have to recognise the shock element," Moody says.
In some situations during his tenure as a CIO, Moody offered to speak with a fired employee a week or two after a dismissal, when the shock had worn off. At that point, he would usually reiterate the reason the employee was let go and offer to answer any questions. If the person seemed receptive, he would discuss what steps he or she could take next. Moody remembers advising one former employee who was dismissed for not performing up to standards to get out of the IT business altogether. "I suggested that he try to make a career in something that he had a passion for," Moody says. "He didn't have a passion for technology." About a year later, the employee called Moody and said he had found success brokering yachts. He had made a new career for himself in sailing, a pursuit he loved, and thanked Moody for his advice.
Not all firings lead to such happy endings, but earnest attempts to help a former employee find a new job or even a new career can help reduce the animosity he or she might feel toward the company. Moody advises directing fired employees to human resources or outplacement consultants immediately so that they can begin preparing for the future right away. That will reduce the possibility that they will stew over the firing and seek revenge.
Of course, a truly determined logic bomber might be motivated enough to counteract any precautionary measures in an effort to strike back after a dismissal. "It's hard to protect against the criminal mind," Moody says. But by handling the firing sensitively and being prepared for the worst, you can reduce the chances of catastrophe.
Take these steps when you have to dismiss a key IS staff member:-- Take away key card access and notify security personnel and receptionists of the dismissal.
-- Consider password changes across the enterprise, including in the voice mail system. The fired employee may remember colleagues' passwords or he may have created phantom accounts.
-- Escort the person out of the building immediately after he has been fired.
This reduces the chance that the employee will do something in anger that he'll regret later.
-- Inspect configurations of all systems to which the fired employee had access. Look for evidence of sabotage, such as a computer virus, or efforts to circumvent firewalls and other security measures.
-- Make sure the employee did not create any new accounts on the system before he left.
-- If you have a Web server, make sure he did not create an opening in the firewall.
-- Assess port configuration vulnerabilities.
-- Consider stepping up audits of log reviews for a couple of weeks.
-- Step up use of intrusion detection systems if you have them.
-- Notify your outsourcers so that they don't inadvertently provide system access to the fired employee.
-- Notify vendors and clients if appropriate. The fired employee may call a vendor and ask for a default password. If you are a provider of technical services, he might try to get that information from clients.
-- Make sure all online purchasing access is revoked.
-- Consider reviewing the employee's recent e-mail messages and files. He may have left clues if he's considering sabotage.
-- Keep one of your backup tapes out of regular rotation. If a fired employee plants a malicious file, it will corrupt backup tapes. The one you've put aside may still be usable.
(Senior Writer Peter Fabris can be reached at firstname.lastname@example.org.)
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.