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.
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:
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,
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.
The city's main claim is that Childs was arrested because he placed the
city systems in jeopardy. However:
At no point did Childs do anything to
damage the network, and the network was never down at any time.
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):
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):
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.
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.
Note that in the first "disrupting or denying computer services" charge,
no computer services were actually disrupted. The only thing denied was
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 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
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.