Terry Childs

What do you do if you are a system administrator, or a database administrator, and your nontechnical supervisor wants the root password? What if you believe they will misuse it and create a serious risk?

What if you simply believe you will be transferred, and lose your influence, if you turn it over?

Even supposing the latter (which may indeed have been the larger issue), Terry Childs appears to have gotten a raw deal.

Childs was a Cisco-certified Internetwork Expert (CCIE) working for San Francisco. For about two years, he was the only person with the router passwords for the city's "fiberWAN" network. His managers apparently saw nothing seriously wrong with this, though they apparently did make intermittent attempts to get Childs to turn over the passwords. Childs even configured the city's routers to resist attempts at password recovery, though it is not entirely clear when he took this step. If he did this after being told to turn over the password in preparation for a transfer, it might be more serious.

By all accounts, Childs seems from the beginning to have been "security-conscious to the point of paranoia". The argument can be made, however, that most good computer-security people are. Though making the routers recovery-resistant may be an extreme step. At what point does "security-conscious" cross the line into criminal denial of service?

In July 2008 there was a reorganization of the city's Department of Technology and Information Systems (DTIS), and Childs was ordered, definitively, to turn over the router passwords. He refused.

At one point Childs attended a meeting at which he was ordered to turn over the passwords publicly. He refused. Some of the people at the meeting were pretty clearly not appropriate candidates for receiving the passwords. There was also an open conference call in progress; Childs had no way of knowing who was on the other end. Still, he could have said, "I will turn over the password to ____", or "tell me to what technical person I should turn over the password, and I will do so".

He was suspended for insubordination on July 9, 2008. He did indeed resist turning over passwords for a couple weeks. However, he had at least some legitimate reasons. Unfortunately, the crime for which he was charged, "disruption or denial of a computer service", applies to much of the daily life of network administrators; the way the law was applied to Childs, it might apply to anyone making a mistake on the job. It almost certainly could apply to anyone standing up for increased security.

Furthermore, the city network was never in fact disrupted.There was no outage, no downtime.

Later that July Childs did turn over the password.

And the city had gone almost two years without the password, with nobody appearing to mind.

The early case documents are back online at http://www.infoworld.com/d/data-management/terry-childs-case-in-its-own-words-928.

Overall, it seems to me that people who work in very structured environments have no sympathy for Childs; he clearly broke the rules. Partly that is not the point; just about everyone agrees his firing was legitimate. It was his arrest and denial of bail that are more controversial.

Even if we stipulate (in the legal sense) that Childs refused to turn over the passwords in order to protect his job:

The Arrest

Childs was arrested by SF police on Saturday, July 12, 2008 (three days after his suspension) on four counts originally described as computer tampering, which eventually became one count of "disrupting or denying computer services" (by not revealing the passwords) and three counts of "providing a[n unauthorized] means of accessing a computer, computer system, or computer network".

The unauthorized-access charges were highly questionable; they were later dropped.

He was never granted reasonable bail, and he remained in prison through his trial and his April 27, 2010 conviction. (He was finally released in May 2011.)

There never was any event remotely resembling computer tampering.

He refused to give the police valid passwords at his arrest (such refusal without having the opportunity to consult with a lawyer is protected by the 5th Amendment, although he did continue to refuse). He eventually gave the passwords to then-mayor Gavin Newsom of SF, on July 21, 2008, while in prison. While to some extent this may have represented a degree of grandstanding, meant to suggest that the San Francisco IT department was so chaotic that only Newsom could be said to be in charge, Childs had a point that organization of the city's IT department was a mess, and there were no clear lines of authority.

There are good reasons for limiting access to such passwords on a need-to-know basis, though refusing to turn them over might be going pretty far. Especially when this locks the owners of the system out.

However, there are some mitigating factors. For one thing, the city had not objected in the past to Childs being the only one with the passwords.

And Childs had plausible reasons to question his supervisors' technical competence, and to believe that the routing configuration might be harmed if these supervisors had access to the routers.

The city claimed, eventually, that Childs refused to turn over the passwords in order to make himself indispensable. There may have been some truth to this. At one point he told a co-worker, when rumors of layoffs were circulating at the time of the July 2008 reorganization,

    "They can't screw with me. I have the keys to the kingdom."

But Childs was the only one with the "keys" for close to two years beforehand. So the password withholding by itself was clearly not motivated by the reorganization.

If you tolerate a situation like Child's long enough, where an employee doesn't turn over passwords, it seems to me you forfeit the right to prosecute that offense.

At the trial, Childs claimed he was only asked (by his supervisors and by the police) for his username and password, not for access to the systems in question (which he could have granted by creating another account). Other accounts claim that Childs clearly knew what his supervisors wanted, and refused to give it to them. Should the supervisors have known what to ask for? (Should people who have no idea what to ask for ever be in charge of IT departments?) Should Childs be able to justify his security concerns based on the fact that the supervisors so clearly did not know what to ask for?

Note that the password in question was not a personal password, but rather an administrative password for a set of Cisco routers. The routers had been configured so as to be difficult to update without the password.

Childs would have had opportunities to negotiate with his supervisors for the handover of the passwords between the July 9 confrontation and his arrest, though he was suspended. But at some point you are allowed just to quit, and not talk further to your former employer after that.

The city's main claim is that Childs was arrested because he placed the city systems in jeopardy. However:

  1. Refusal to share passwords is complicated to see as a criminal act. After all, Childs could always quit. Or, for that matter, die. The city's legal position appears to have been that by refusing to hand over passwords, Childs was guilty of "denying access".
  2. The city knowingly created and encouraged the environment in which Childs was the only one with the passwords.
  3. No working systems were ever at risk.

At no point did Childs do anything to damage the network, and the network was never down at any time.


Bail

Childs' bail was set at $5 million; reductions were routinely denied. What is it about computer crime that so terrifies the authorities?

Typically, bail for a single murder is set at about $1 million. Jerry Sandusky, the Penn State coach accused of raping children, at one point had bail set at $250,000 (for ~10 vicims). That is probably less than 1 year's salary; Child's bail was probably about 50 years' salary.

It is not clear what led to Childs' arrest on July 12, let alone the denial of bail.

One possible reason Childs was denied reasonable bail is the fact that a search of his residence just before his arrest turned up some 9mm ammunition, and Childs had in 1985 been convicted of a felony: armed robbery (with a knife). Possession of ammunition by a convicted felon is illegal in California (and many other states). Also, the fact that Childs had $10,000 in cash in his house was interpreted by the police as evidence that he was a flight risk. These may have greatly influenced the judge's decision to deny reasonable bail.

Finally, Childs lied to his supervisors when he said he had no past felony convictions, and lied again on the day of his management confrontation when he said his fiberWAN password no longer worked. Both of these are perhaps understandable, and in principle they shouldn't matter, but one doesn't know.

In opposing bail reduction for Childs, the city's attorneys wrote the following in late July 2008; the accusations here are mostly technically misinformed (see also the following section):

In the training room locked by the Defendant, they discovered two modems that allowed access to the City's network from unauthorized locations. A further analysis of the network by Principle Security Consultant Anthony Maupin determined that the Defendant had configured multiple Cisco network devices with a command that erases all configurations and data in the event somone tried to recover the password. Further, the Defendant had created his own private network that bypassed all City monitoring and security systems. He had programs that monitored and detected any intrusions and notified the Defendant if others were monitoring or trying to access his information. The Defendant had implemented his own email server and had multiple remote access systems, some which [sic] were hidden in locked storage cabinets and connected to modems. This permitted the Defendant to access the City's network infrastructure undetected. An additional modem was discovered in a locked cabinet near his cubicle that was connected to a phone line and had access to the network.

... There are over 1100 different devices, routers, switches, modems, etc, scattered throughout the  city's offices that the Defendant may have configured and even locked with his own passwords.  ... there is a serious threat to the City's network system if the Defendant was out of custody without the City having full control over all the 1100 devices as the Defendant may have access any of these devices [sic].

Alas, the city made similar arguments at later bail hearings as well. There may be a case to be made for denying bail in the immediate aftermath of a security incident, to give new managers time to close the loopholes. But this should not continue! And there was, arguably, no "incident" in Childs' case.

The initial four official charges (with none of the tantalizing allegations of the bail-reduction motion making it in): The latter three charges were finally dropped on August 21, 2009, over a year later. Bail, however, remained at $5 million, even though the state's original argument against bail reduction was based on three dropped charges and the idea that the "unauthorized" modems might mean that Childs had other back-doors into the city network. Childs was denied reasonable bail, in effect, for inappropriate reasons.

Also, San Francisco had plenty of time to tighten up security. It is possible that the three dropped "unauthorized modem" charges were dropped because of the impossibility of proving that they were in fact unauthorized, though that is to some extent exactly the defense's point.

It does seem likely that a big part of the reason Childs remained in jail was that the City kept raising the specter that he could break in to the city network if he were ever released. But if he could, even a few months later, let alone close to two years, then so could anyone else, and the City's security is just plain negligent.

Ultimately, the refusal of the courts to consider bail was perhaps the most unsettling part of the case, even if you believe Childs was being intentionally uncooperative.

Random Accusations

Along with denial of bail, the other big concern to computing professionals was the fact that San Francisco created a laundry list of criminal allegations against Childs that in fact are standard practices:
  1. Childs knew several other people's passwords. (A list of 150 such was found in Child's house, and entered into evidence at his bail hearing without redacting the passwords themselves.)
  2. He had network sniffers in place (see previous section)
  3. He had "back-door" access to the routers, through several modems (three in the final criminal count); see the previous section. But these were pretty clearly for emergency access.
  4. Childs' pager was sent a page by one of the routers (duh)
  5. Childs ran his own email server (see previous section)
  6. Childs could access the city network undetected
  7. Routers were configured to resist password recovery (this is standard practice when the physical security of the device is in question).
  8. Configurations were not written to flash memory
Except for #3, Childs was not actually charged for any of these, but #1 figured significantly into the restitution order, and all were used to demonstrate Childs' poor character.

Regarding #1 here, the city later sued Childs for damages. A significant part of this had to do with the need to change the passwords discovered in Childs' home. But the primary reason to change the passwords was that the state published the password list in court documents.

The modems from #3 above were all apparently legitimate: the first was to dial Childs' pager if there was a problem (through the "What's Up Gold" monitoring package), the second was to allow immediate dial-in access to some SF networks (not apparently the FiberWAN), and in addition was apparently installed before Childs was hired, and the third was to provide an alternative communications paths to emergency services across the San Andreas fault. (See http://www.infoworld.com/d/data-management/could-childs-case-put-all-network-admins-in-danger-979)

As for #7 and #8, it is indeed possible that Chilthe damagesds decided not to have configurations written to flash memory for "job security"; ie so that, if there was a problem, he would be irreplaceable. Alternatively, it could have been because Childs was having conflicts with management and wanted them to know they couldn't work without him. However, San Francisco's contribution to the situation, and the city's long-standing acceptance of the situation, are contributory.

The arrest-warrant affidavit of police officer James Ramsay states:

Mr Maupin [the city's security consultant] was also able to determine and validate that Mr Childs had, in fact, intentionally configured multiple Cisco network devices with a command that erases all configuration and data in the event that someone tries to restore administrative access or tries to perform disaster recovery. This command was created for military applications that require the deployment of network devices in areas that may have the possibility of hostile forces that could get physical access to network devices.

(Officer Ramsay also was the one to tell Childs initially that failure to divulge the passwords was "a denial of service as defined under Penal Code violation Section 502(c)(5)".) This claim about the routers remains farfetched, at face value, given the lack of clear authority within DTIS, although it might apply if Childs had withheld the password with malicious intent. But this was never directly claimed.

Note that the quoted line "this command was created for military applications ..." is both misleading and a bit of a stretch. It seems likelier that the command was suggested for military applications, but even if it was created for that, so was GPS.

As for the configuration-to-erase claim, Childs' attorneys provided in his bail-reduction motion a reasonable justification for this setting: one of his colleagues, Carl Sian, intentionally kept (as for study) computer viruses, and later spread one to Childs (possibly accidentally). In a later episode, Childs' supervisor Herb Tong made some changes to the fiberWAN system that Childs felt were technically inappropriate. In light of those events, "hardened" configuration of the routers is hard to see as inappropriate.

Childs may also, like some other security people, simply have decided to apply every security mechanism that was available to him.

The Act Itself

After the unauthorized-access charges were dropped, Childs stood formally charged with only However,

Note that in the first "disrupting or denying computer services" charge, no computer services were actually disrupted. The only thing denied was the password.

He did configure the network in a manner that made it difficult for coworkers to reconfiguring it. Was this about prudence, or job security? He apparently did not face day-to-day clear lines of authority; he definitely was not asked to make the master passwords available to supervisors until the Dispute.

There were no charges of network tampering; these appeared in court documents in July and August 2008 but were dropped. ("Network tampering" appears to have been replaced by the three modem charges.)

The formal allegation against Childs did not spell out any specific evidence of intent to disrupt the network (though it did not have to). Evidence was presented at the trial, though, that Childs did indeed intend to give himself "job security" by making sure no one else could manage the network.


Here are a couple comments from one of the jurors, Jason Chilton, who, like Childs, was a CCIE.

The questions were, first, did the defendant know he caused a disruption or a denial of computer service. It was rather easy for us to answer, "Yes there was a denial of service." And that service was the ability to administer the routers and switches of the FiberWAN.

Is refusing to turn over a password really a denial of service? It seems more like a denial of potential service. Is refusing to turn over passwords a denial of a "computer service", given that all routing and software continued to run properly? Do software developers face denial-of-service charges if they withhold certain notes as to how an application works? What about network administrators who quit without completing certain network-architecture documentation that the employer asks for?

That was the first aspect of it, the second aspect was the denial to an authorized user. And for us that's what we really had to spend the most time on, defining who an authorized user was. Because that wasn't one of the definitions given to us.

One of Childs' points was that it wasn't clear to him who was an "authorized user", hence the eventual turning over of the passwords only to the mayor.

Chilton also clearly believed the job-security theory; here's a quote from blogs.sfweekly.com/thesnitch/2010/08/terry_childs_sentenced_hacker.php:

It almost seemed like paranoia. Especially after he found out there would be some organizational changes, I believe the security he was putting in place wasn't to prevent attackers but to prevent people from getting rid of him. He would be needed because no one else could take care of this network. It was so secure, only he could have access.
is
Chilton says "I believe" here. He does not say "I was convinced by the evidence that".

On August 6, 2010, Childs was sentenced to four years in prison. He was released by May 2011. If Childs did indeed intentionally try to make the system inaccessible to anyone else, for job security, then some penalty is appropriate. But four years is an extraordinary sentence if you believe the case was the result of a workplace misunderstanding.

On October 25, 2013, the California Court of Appeals upheld the requirement that Childs pay restitution of $1.5 million. His legal theory for the appeal was apparently that the California computer law was not meant to cover employees; that is something of a stretch. More compelling arguments against full restitution are that the city released the passwords that had to be changed, and that once Childs turned over the passwords, there was no longer any need for restitution.