Disgruntled Former Worker Who Hijacked Network Must Pay City $1,485,791
In a recent survey of 500 information technology and data security workers, 40 percent said they could easily use their knowledge of encryption keys, shared passwords, weak controls and loopholes in data security programs to make off with information, or hold their organization’s data hostage. And 31 percent said that, even if they no longer worked for the company, with their knowledge of the systems they could access encryption keys and authorization codes and hack in remotely to snoop, secretly alter files or shut down the data system.
Digital security firm Venafi discovered that firms that mismanage their encryption keys could fall victim to disgruntled former employees hiding or withholding encryption keys to the detriment of the firms. This threat has been attributed to lack of internal controls, poor management and failing to understand how weak management of encryption keys, data and security can hurt their organizations.
The survey shows that 82 percent of companies now use digital certificates and encryption keys to protect digital assets and to secure sensitive system communications. However, 43 percent admit to being locked out from their own information because people have left the organization or keys were lost.
The survey reveals that organizations need to come to terms with how crucial encryption keys are to safeguarding the entire enterprise, but even more critical it is to monitor and manage who has access to them!
A good example stems from a recent US case.
In April 2010, Terry Childs, a former IT employee with the City of San Francisco was sentenced to four years in prison for blocking access to the city’s network (which he designed) and refusing to turn over the passwords. It took Childs 12 days in prison to provide the passwords to the mayor, whom he claimed to be the only person with the right to receive the passwords according to company policy. During Childs’s silence, city employees were unable to access police records, payroll data and other information.
On May 17, 2011, Childs was back in the news when it was reported that he would also be fined a significant amount in restitution to the city: $1,485,791! City officials claimed that was how much it cost them to try and break into their own network during the standoff and test for vulnerabilities after the incident.
According to court filings, this incident was a culmination of a long-simmering dispute between Childs and his managers, who had been seeking administrative passwords to the network. Childs had refused to provide the passwords, supposedly because the people asking were not authorized to receive them, and he feared that they would be shared with management or outside contractors. He argued that “his actions, depicted as criminal by prosecutors, were in line with standard network security practices.”
According to the city, Childs was disgruntled because he found out his job was in jeopardy and was trying to make himself indispensable to the city’s IT department.
Commentators are arguing that this additional punishment is way too harsh and the amount way too high since no hardware was damaged by Childs and the vulnerability testing should have been done anyway. They also add that the city needs to be held accountable for allowing a system in which only one person knows the passwords in the first place, after all, what would have happened if Childs had been hit by a bus?
Others think there is more to the story.
Regardless, this case and the Venafi survey are strong warnings to businesses that they cannot necessarily entrust their sensitive data to the whims of a few highly skilled IT employees—or former employees. The Globe article offers some suggestions on how to address the problem, but it really comes down to clear communication with security contractors and IT staff, and clear and binding internal policies with respect to security and employment. Staff must understand their obligations to their employer and the organization’s data both during their employment and after, and these obligations should exist in writing.
It’s also probably a good idea to make sure that a single person doesn’t control access to your entire network.
Comments are closed.