Slashdot Mirror

http://www6.sfgov.org/index.aspx?page=246
there are other cities with public wifi too, but off hand i recall SF uses 5ghz directional to carry the 2.4ghz hotspot around the city, the internet archive also has input into the building of the network, as they did it with their own 100 mbit link prior to the city doing it. this is all from memory so if i'm wrong i'm wrong.

Because when you divert 75% of compostables and recyclables out of the landfill, not only do you need 75% less landfills, but you can afford to build them better.

Oh, yeah...that sounds like something that will actually happen.

What? 75% diversion? San francisco is at 77%, Seattle hit 53% in 2010 with a goal of 60% in 2012. Single family homes were at a 70% diversion rates in Seattle in 2010.

Withholding his password is fine, but he also refused to give admin access to people he _knew_ were authorised for it.

Cite? The way I heard it, he was asked on a phone call [strike 1: "Giving your password over the phone to ANYONE."] by his superior [strike two: "Telling your boss your password"] to hand over the passwords. Did I mention this was a conference call with god knows who else listening? [strike 3: "Talking about a password in front of others".]

Those 'strikes' are from here: http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf , "California Counties “Best Policies” for the Countywide Information Security Program".

He was fired and refused to release property that belonged to his former employer. Period, end of story.

The agreement he had with his (former) employer specifies who he was to release that information to, and under what circumstances. The request did not come from an authorized person, and the circumstances were suspect.

If you work helpdesk in a corporate environment, you might need to handle passwords. If the rules say you are only allowed to give out a an employees password to the employee, you don't give the passwords to anyone else. Not even the employees boss, or the employees boss's boss. Not even your boss, or the CEO. NO ONE, except the employee.

That's basically what happened here.

http://www.cio.com.au/article/255165/sorting_facts_terry_childs_case/?fp=&fpid=&pf=1

"...what actually happened was that Childs refused to provide his superiors the passwords to the city's core FiberWAN network, effectively preventing them from administering the network. The network continued to function, and no city applications, data, or resources were lost or inaccessible."

Lets see what the "California Counties “Best Policies” for the Countywide Information Security Program" [ http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf ] has to say about that:

"Here is a list of things to avoid:
  Giving your password over the phone to ANYONE. ...
  Telling your boss your password"

So, the "Best practices" told him to NOT give his superiors the password, and certainly not over the phone (as they requested).

tl,dr: He followed the rules, and got screwed for it.

Except that Childs would have been breaking the law to hand over his password to his supervisor as that is directly addressed in the password policy for San Francisco.

"Password Policy"
As such, all County employees (including contractors, vendors, and temporary staff with access to County systems) are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords.
All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed on at least a monthly basis"
"Do not share County passwords with anyone, including administrative assistants or secretaries.

All passwords are to be treated as sensitive, confidential County information.

Here is a list of things to avoid
-Telling your boss your password.
-Talking about a password in front of others.
-Telling your co-workers your passwordwhile on vacation."

http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

"Password Policy"
As such, all County employees (including contractors, vendors, and temporary staff with access to County systems) are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords.
All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed on at least a monthly basis"
"Do not share County passwords with anyone, including administrative assistants or secretaries.

All passwords are to be treated as sensitive, confidential County information.

Here is a list of things to avoid
-Telling your boss your password.
-Talking about a password in front of others.
-Telling your co-workers your passwordwhile on vacation."

http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

All production system-level passwords must be part of the security administered global password management database.

Terry Childs did the right thing by not giving out the passwords to anyone but the Mayor.

Here we go again with this bullsh*t!. You are absolutely incorrect. According to the very same policy that you're selectively quoting from, it states:

All production system-level passwords must be part of the security administered global password management database.

Terry Childs was required by policy to make these "system level" passwords available. This was nothing more than arrogant grandstanding. The guy decided to try to play hardball, and he got taught a lesson.

According to everything I have read he refused to hand over the password under any circumstance when his supervisors asked for them. There was no "only give to the mayor" rule. He was a regular employee working a regular job where he has the obligation to hand over information requested by his supervisor

I'll post this again, and bold the important part.

"Password Policy"
As such, all County employees (including contractors, vendors, and temporary staff with access to County systems) are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords.
All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed on at least a monthly basis"
"Do not share County passwords with anyone, including administrative assistants or secretaries.

All passwords are to be treated as sensitive, confidential County information.

Here is a list of things to avoid
-Telling your boss your password.
-Talking about a password in front of others.
-Telling your co-workers your password while on vacation."

http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

The city password policy was to NOT give it to your boss. He followed the city policy, which his boss did not abide by, as he first tried to get the passwords, and also, attempted to get the password in front of others. But that's a moot point. He had been fired before his former boss asked him for the password. City protocol was to request a password in writing, again, which his former boss had not done. So your entire argument crumbles.

Here's an earlier comment that discusses the city policy.

And here's a quote from the password policy of the city, which is in that link:

"Password Policy"
As such, all County employees (including contractors, vendors, and temporary staff with access to County systems) are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords.
All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed on at least a monthly basis"
"Do not share County passwords with anyone, including administrative assistants or secretaries.

All passwords are to be treated as sensitive, confidential County information.

Here is a list of things to avoid
-Telling your boss your password.
-Talking about a password in front of others.
-Telling your co-workers your password while on vacation."

http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

As we can see from the city policy, telling your boss is already out, and talking about your password in front of others (the individuals on the other end of the phone line) is also a no-no. Terry Childs did the right thing by not giving out the passwords to anyone but the Mayor. Did Childs' boss ever get in trouble for breaching city policy? Probably not.

Written IT policy for the CCISDA states that all administrative passwords must be stored in the "global password management database". See here page 34. Had he done this, the entire password conversation never would have been necessary. I'm guessing that his dismissal was related to his refusal to put the password in the database.

He was given the option to hand over the passwords and walk away or face jail time.

You misspelled some words.

I think you mean: He was given the option to commit a fellony carrying a manditory 20 year prison sentence, or to face jail time

He still made the right choice. Given no other options, 5 years in jail is more than 4x better than 20 years in federal prison.

http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

It specifically states the CIO are to report directly to the Operational Security Manager only in such matters.
Hi's boss and his bosses boss are NOT in that position.

Of course I'm sure YOU would have done the 'right' thing and be in federal prison right now laughing it up, right?

Disclosing your password to your boss is specifically prohibited(PDF, page 34) by California's password policy.

That appears to be regarding specific user passwords to user accounts. It does not apply to system level passwords for systems you are caretaker to.

It is correct that you should never give the password to your own accounts to anyone at all. If they need the data/access you have, they will either have their own account or be able to get one with that access. Or at the very least they will be able to change your password to another one. The access to the data that they own is never in any doubt because they have the ability to override you without compromising your personal password.

However, if they do not have access to the superuser passwords or other such administrative credentials, they actually do lose that data if you refuse to give it to them. Root passwords should not be given out to non-technicals all that often, but if there is no technical person left, you can't just take access to those hosts/devices with you. Even if it's not illegal, its simply not right.

Disclosing your password to your boss is specifically prohibited(PDF, page 34) by California's password policy.

"Chairperson Robinson announced that DTIS internally hired the new Security Manager, Jeana Pieralde. He stated that a memo went out asking departments who their IT security contact person with the plan to implement a security IT work group within the City"

Why are there no reports about others involved in this case?

"The office from which Pieralde removed the hard drive belonged to DTIS Security Officer Nancy Hastings (who naturally was not present in the office because the "security audit" was being conducted after hours.)

Terry Childs had returned late to the offices (which do include his office and do not include Jeana Pieralde's office) at about 5:15 P.M. to find Jeana Pieralde (who does not work in those offices) taking a hard drive from one of Terry's co-workers offices. Terry photographed this act with the camera in his cellphone.

Jeana Pieralde then involved DTIS Deputy Director Rich Robinson. Rich called Terry and told him to stop taking pictures.

Three days later (Monday) both Rich Robinson and Jeana Pieralde filed complaints of threats with the San Francisco police department and Police Inspector James Ramsey was assigned to the case. No charges have ever been filed against Terry Childs for the alleged threats (which included the statement "I'm ready for you Rich. Or I can come up to your office.")"

"5. Mr. Childs clashed with the new Security Manager on the subject of authentication and control, which led to poor formal review"

In early June, Terry Childs sent repeated complaints of incompetency regarding a supervisor (Herb Tong) to that supervisor's superiors. When nothing was done about the informal complaints, Terry Childs filed a formal complaint regarding the supervisor (Herb Tong.) It was several weeks later, on the 20th of June that the reported clash with the new (position created and filled just this year) Security Manager (Jeana Pieralde) occurred.

The Security Manager position was new. Jeana Pieralde was promoted from a prior position within DTIS to the Security Manager position. Jeana Pieralde no longer worked in the same offices with Terry Childs. He returned to those offices on the evening of June 20th, 2008 after normal office hours (which end at 5 P.M.) to find Jeana Pieralde removing a hard drive from someone else's office. She claimed to be performing an unannounced audit.

Jeana Pieralde is the author of a proposed security policy for the city which is still waiting for committee review. That security policy, if accepted, may one day give Jeana Pieralde specific authority to perform audits and perhaps even to have administrative control over city communications networks.

Please dig deeper into this story"

Page 32, section 4.1 ...

"All production system-level passwords must be part of the security administered global password management database."

County policy document

Section 4.1, page 32.

"All production system-level passwords must be part of the security administered global password management database."

The actual county policy document

In section 4.1 (page 32) we see...

"All production system-level passwords must be part of the security administered global password management database."

Policy says don't give passwords to your boss, don't give password over the phone, don't give password in front of others. they asked him for the password in a room full of people and an open speakerphone and he refused. Somewhere in there either before or after this he was fired. Once they fired him he was under no obligation anyway IMO but in any case he was following the written policy! The policy also stated that you could be in for both civil or criminal proceedings for not following the policy...

You should also note that one of the folks asking was a woman he'd caught sneaking around office spaces she had no business being in and he claims he caught her removing a HDD from a computer, that's part of what started all of this. For all he knew they were attempting to hack passwords or plant evidence. After having been caught she claimed it was part of an investigation but no one was notified about the investigation ahead of time. considering the sorts of data that network protected wouldn't you be a bit suspicious and paranoid?

http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

The Govt's policy specifically mentions not giving passwords to your boss. It also mentions not discussing them over the phone and not discussing them in front of a group of people. http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

Now you can, and you're absolutely right.

It was a written policy. You can find the base document here: http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

Sure:

The overall policy page is:
http://www.sfgov.org/site/coit_index.asp?id=56853

The security policy is specifically:
http://www.sfgov.org/site/coit_page.asp?id=79251

Which basically says "follow the County security policy until we come up with something different"
http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf [sfgov.org]

It could be the case that the committee has since eliminated/altered that paragraph, but if they have, they haven't updated that section of their website.

Sure:

The overall policy page is:
http://www.sfgov.org/site/coit_index.asp?id=56853

The security policy is specifically:
http://www.sfgov.org/site/coit_page.asp?id=79251

Which basically says "follow the County security policy until we come up with something different"
http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf [sfgov.org]

It could be the case that the committee has since eliminated/altered that paragraph, but if they have, they haven't updated that section of their website.

Sure:

The overall policy page is:
http://www.sfgov.org/site/coit_index.asp?id=56853

The security policy is specifically:
http://www.sfgov.org/site/coit_page.asp?id=79251

Which basically says "follow the County security policy until we come up with something different"
http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf [sfgov.org]

It could be the case that the committee has since eliminated/altered that paragraph, but if they have, they haven't updated that section of their website.

No reference? Right in the middle of the "don't" list in the City's policy is "Do NOT disclose passwords to your boss".

Here, I'll quote it for you:

Do not share passwords with anyone, including administrative assistants or secretaries. All passwords are to be treated as sensitive, confidential information.

Here is a list of things to avoid:

• Giving your password over the phone to ANYONE.
• Sending a password in an e-mail message.
• Telling your boss your password .
• Talking about a password in front of others.
• Hinting at the format of a password (e.g., "my family name").
• Writing in your password on questionnaires or security forms.
• Sharing your password with family members.
• Telling your co-workers your passwordwhile on vacation.

If someone demands a password, refer him or her to this document or have him or her call someone in Information Security.

If you look at the corresponding satellite image it's a specific tree in Golden Gate Park in an area called "Speedway Meadow". It is right beside half a dozen picnic tables and it is about 100m from an outdoor stage. According to other information about the park, this area has barbeque pits.

I used the San Francisco Parks Portal to search for events scheduled on that day in Speedway Meadow. Nothing specific shows up.

Since you seem to be unable to read the actual article, here is the link from it:

http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

the bottom most gray box has the relevant excerpt from the policy. I believe even according to the policy, Childs shouldn't have given the password to the Mayor, but this seemed to be a compromise as he realized it would be needed to hand them over to someone. Personally, if my company brought me into a room with a speakerphone connected to unknown people, and no one that should be getting the passwords in the room, I wouldn't give them out either. The policy may state that he should notify the Information Security department of anyone requesting your password, but I cannot see where it says you should give them to these people, and it specifically says not to ever give out your password over the phone, which I would assume the speakerphone connected to unknown people would fall under.

Please, do your own due diligence before slamming someone else's post, the links I used to pull up the doc came from that site, but the PDF of the policy most assuredly came from SF's gov.

Here is the relevant policy, refer to the section starting on page 32...

http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

According to the policy, he was supposed to have the passwords in a global, heavily-protected database. Whether he did or did not is open for debate. I don't know. And that could be a source of trouble to him.

According to the charges, he did not surrender the passwords to a group of people, many of whom were unknown to him, and many others of whom were clearly not authorized to possess that information, many of whom worked for different departments in different capacities, in the presence of an open microphone on a speakerphone with participants of unknown identity and number. In the context of that meeting, it would be a clear violation of the policy the city maintains to disclose those passwords, as the disclosure would have simultaneously violated at least two lines in the "forbidden" list, as followed (clear violations in bold):

Here is a list of things to avoid:
Giving your password over the phone to ANYONE.
  Sending a password in an e-mail message.
Telling your boss your password .
Talking about a password in front of others.
  Hinting at the format of a password (e.g., “my family name”).
  Writing in your password on questionnaires or security forms.
  Sharing your password with family members.
  Telling your co-workers your passwordwhile on vacation.

Maybe he didn't put the passwords in the global database, and maybe he deserves punishment for that.

But as to that meeting, it appears that he did his job.

Except that the policy of SanFran (quoted in a response to previous article on Slashdot, so I'm going to be lazy and let you do your own damn research for once) SPECIFICALLY required that he not reveal the passwords to anyone but the mayor, and certainly not to someone on an open fucking conference call to which anyone else, especially the "spy girl" who he had turned in when he caught her rummaging through shit after hours, might have been party.

He delivered the passwords, AS PER WRITTEN SANFRAN POLICY, to the Mayor in a face-to-face meeting. That is what was required of him by SanFran code. The people who tried to get him to break that policy are the idiots who should lose their jobs and be on trial.

This is rapidly becoming myth rather than fact-based.

The overall policy page is:
http://www.sfgov.org/site/coit_index.asp?id=56853

The security policy is specifically:
http://www.sfgov.org/site/coit_page.asp?id=79251

Which, basically, says "follow this inter-county planning document":
http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

The password policy in CCISDA states:

(pp 32 of the document)

4. Policy
4.1. General
All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed on at least a monthly basis.
All production system-level passwords must be part of the security administered global password management database.

(removed)

B. Password Protection Standards
Do not use the same password for County accounts as for other non-County access (e.g., personal Internet Service Provider (ISP) account, option trading, benefits, etc.). Where possible, don’t use the same password for various County access needs. For example, select one password for the network systems and a separate password for application systems. Also, select a separate password to be used for a NT account and an AS400 or UNIX account.
Do not share County passwords with anyone, including administrative assistants or secretaries. All passwords are to be treated as sensitive, confidential County information.
Here is a list of things to avoid:
Giving your password over the phone to ANYONE.
Sending a password in an e-mail message.
Telling your boss your password .
Talking about a password in front of others.
Hinting at the format of a password (e.g., “my family name”).
Writing in your password on questionnaires or security forms.
Sharing your password with family members.
Telling your co-workers your passwordwhile on vacation.
If someone demands a password, refer him or her to this document or have him or her call someone in Information Security.
Never use the “Remember Password” feature of applications (e.g., Eudora, Outlook, Netscape Messenger).
If you must your passwords down, store them is a secure place and never anywhere in your office.
Passwords stored in a file on ANY computer system (including Palm Pilots or similar devices) can be compromised if encryption isn’t used to secure them.
Change passwords at least once every three months (except system-level passwords, which must be changed monthly). Changing them more often is better.
If you suspect that your account or password is compromised, report the incident per the Incident Response Policy and change all passwords.
Password strength checking may be performed on a periodic or random basis by departmental or county IT or its delegates. Any passwords found out during one of these scans will require the user to change it.

Though the "Do not tell anyone your password" sect

Except that the policy of SanFran (quoted in a response to previous article on Slashdot, so I'm going to be lazy and let you do your own damn research for once) SPECIFICALLY required that he not reveal the passwords to anyone but the mayor, and certainly not to someone on an open fucking conference call to which anyone else, especially the "spy girl" who he had turned in when he caught her rummaging through shit after hours, might have been party.

He delivered the passwords, AS PER WRITTEN SANFRAN POLICY, to the Mayor in a face-to-face meeting. That is what was required of him by SanFran code. The people who tried to get him to break that policy are the idiots who should lose their jobs and be on trial.

This is rapidly becoming myth rather than fact-based.

The overall policy page is:
http://www.sfgov.org/site/coit_index.asp?id=56853

The security policy is specifically:
http://www.sfgov.org/site/coit_page.asp?id=79251

Which, basically, says "follow this inter-county planning document":
http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

The password policy in CCISDA states:

(pp 32 of the document)

4. Policy
4.1. General
All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed on at least a monthly basis.
All production system-level passwords must be part of the security administered global password management database.

(removed)

B. Password Protection Standards
Do not use the same password for County accounts as for other non-County access (e.g., personal Internet Service Provider (ISP) account, option trading, benefits, etc.). Where possible, don’t use the same password for various County access needs. For example, select one password for the network systems and a separate password for application systems. Also, select a separate password to be used for a NT account and an AS400 or UNIX account.
Do not share County passwords with anyone, including administrative assistants or secretaries. All passwords are to be treated as sensitive, confidential County information.
Here is a list of things to avoid:
Giving your password over the phone to ANYONE.
Sending a password in an e-mail message.
Telling your boss your password .
Talking about a password in front of others.
Hinting at the format of a password (e.g., “my family name”).
Writing in your password on questionnaires or security forms.
Sharing your password with family members.
Telling your co-workers your passwordwhile on vacation.
If someone demands a password, refer him or her to this document or have him or her call someone in Information Security.
Never use the “Remember Password” feature of applications (e.g., Eudora, Outlook, Netscape Messenger).
If you must your passwords down, store them is a secure place and never anywhere in your office.
Passwords stored in a file on ANY computer system (including Palm Pilots or similar devices) can be compromised if encryption isn’t used to secure them.
Change passwords at least once every three months (except system-level passwords, which must be changed monthly). Changing them more often is better.
If you suspect that your account or password is compromised, report the incident per the Incident Response Policy and change all passwords.
Password strength checking may be performed on a periodic or random basis by departmental or county IT or its delegates. Any passwords found out during one of these scans will require the user to change it.

Though the "Do not tell anyone your password" sect

Except that the policy of SanFran (quoted in a response to previous article on Slashdot, so I'm going to be lazy and let you do your own damn research for once) SPECIFICALLY required that he not reveal the passwords to anyone but the mayor, and certainly not to someone on an open fucking conference call to which anyone else, especially the "spy girl" who he had turned in when he caught her rummaging through shit after hours, might have been party.

He delivered the passwords, AS PER WRITTEN SANFRAN POLICY, to the Mayor in a face-to-face meeting. That is what was required of him by SanFran code. The people who tried to get him to break that policy are the idiots who should lose their jobs and be on trial.

This is rapidly becoming myth rather than fact-based.

The overall policy page is:
http://www.sfgov.org/site/coit_index.asp?id=56853

The security policy is specifically:
http://www.sfgov.org/site/coit_page.asp?id=79251

Which, basically, says "follow this inter-county planning document":
http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

The password policy in CCISDA states:

(pp 32 of the document)

4. Policy
4.1. General
All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed on at least a monthly basis.
All production system-level passwords must be part of the security administered global password management database.

(removed)

B. Password Protection Standards
Do not use the same password for County accounts as for other non-County access (e.g., personal Internet Service Provider (ISP) account, option trading, benefits, etc.). Where possible, don’t use the same password for various County access needs. For example, select one password for the network systems and a separate password for application systems. Also, select a separate password to be used for a NT account and an AS400 or UNIX account.
Do not share County passwords with anyone, including administrative assistants or secretaries. All passwords are to be treated as sensitive, confidential County information.
Here is a list of things to avoid:
Giving your password over the phone to ANYONE.
Sending a password in an e-mail message.
Telling your boss your password .
Talking about a password in front of others.
Hinting at the format of a password (e.g., “my family name”).
Writing in your password on questionnaires or security forms.
Sharing your password with family members.
Telling your co-workers your passwordwhile on vacation.
If someone demands a password, refer him or her to this document or have him or her call someone in Information Security.
Never use the “Remember Password” feature of applications (e.g., Eudora, Outlook, Netscape Messenger).
If you must your passwords down, store them is a secure place and never anywhere in your office.
Passwords stored in a file on ANY computer system (including Palm Pilots or similar devices) can be compromised if encryption isn’t used to secure them.
Change passwords at least once every three months (except system-level passwords, which must be changed monthly). Changing them more often is better.
If you suspect that your account or password is compromised, report the incident per the Incident Response Policy and change all passwords.
Password strength checking may be performed on a periodic or random basis by departmental or county IT or its delegates. Any passwords found out during one of these scans will require the user to change it.

Though the "Do not tell anyone your password" sect

According to the affidavit, he was asked for the password by the General Security Manager, and the Directory of Security. Both were authorized to request that information. It's stated directly in the password policy that if someone asks for a password, that the employee is to contact Security (who also published the policy btw).

No where in the password policy does it even mention the mayor. I find it amusing that people on here are running with that. The mayor came into it because according to a quote from Childs, he "felt the mayor was the only person he could trust". The mayor has nothing to do with the password policy nor was he listed as an 'authorized requester'.

http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

He was also no longer in charge of the network you're referring to. He was removed from that group when they found that he wasn't following policy. He refused to supply the password to Security per the password policy. It states that all system passwords must be placed into a Security managed database.

Case Affidavit:
http://weblog.infoworld.com/venezia/childs/tcramsay_affidavit1.pdf [infoworld.com]

Security requested the passwords from him, and they were authorized to access such information (they established the password policy to begin with and noted in the policy that if someone had questions they should contact Security). Both the manager of security and the Director of Security request the password from him, yet he refused or gave them bad credentials. They password policy itself stated that all system passwords must be kept in a security managed database. It is the primary reason his employment was terminated according to the affidavit.

County Security Policy (see section 4 for the password policy):
http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf [sfgov.org]

When security asked for the password, he was removed from his position for failing to comply (insubordination). Security was authorized to access those passwords per the policy so many are claiming is his defense. He was in violation of the password policy for not putting the passwords under Security's care to begin with.

(from section 4.1 of the General Security Policy)
"All production system-level passwords must be part of the security administered global password management database."
"If someone demands a password, refer him or her to this document or have him or her call someone in Information Security."

It was Security that was asking for the password.

By refusing to supply the passwords he put the network at risk. Per the affidavit, he actually told the director of security when asked if he implemented disaster recovery procedures, documented the network under his control, and/or if he had made the required backups on devices, as policy. His answers were "..no..". In the event of a failure, the city would have been screwed.

"he was still under no legal obligation to expose passwords to systems that he protects. "

He was also no longer in charge of the network you're referring to. He was removed from that group when they found that he wasn't following policy.

http://weblog.infoworld.com/venezia/childs/tcramsay_affidavit1.pdf

Security requested the passwords from him, and they were authorized to access such information (they established the password policy to begin with and noted in the policy that if someone had questions they should contact security). Both the manager of security and the director request the password from him, yet he refused. They password policy itself stated that all system passwords must be kept in a security managed database. This is the primary reason he was terminated.

http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

I guess we'll just have to wait and see if they consider the passwords company property.

According to the password policy, Childs was already in violation by refusing to place the password in a security administered global password management database.

From Section 4.1 (general) of the Password Policy:

"All production system-level passwords must be part of the security administered global password management database.". Security did ask him for these passwords and he refused.

I see no where in the policy that said it's a violation of policy to give authorized individuals the passwords. Considering that the security manager and the Director of Security asked for the password, I don't see the issue since these are the folks who publish the password policy. The policy itself refers you to Security.

"If someone demands a password, refer him or her to this document or have him or her call someone in Information Security."

Link to affidavit:
http://weblog.infoworld.com/venezia/childs/tcramsay_affidavit1.pdf

Link to security policy:
http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

It would seem the prudent thing to do, if you find yourself in a similar situation, would be to turn over the damn passwords.

Hmmm ... Apparently you missed the earlier post's link to the article about the official policy of the county government. It included this summary excerpt:

"Password Policy"
As such, all County employees (including contractors, vendors, and temporary staff with access to County systems) are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords.
All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed on at least a monthly basis"
"Do not share County passwords with anyone, including administrative assistants or secretaries.

All passwords are to be treated as sensitive, confidential County information.

Here is a list of things to avoid
-Telling your boss your password.
-Talking about a password in front of others.
-Telling your co-workers your password while on vacation."

http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

So if he'd handed over the password to his bosses, he would have been charged with a violation of official published policy, and that charge would have probably stuck. By following the official policy, he may well have succeeded in winning the court case. Of course, it didn't stop the city from implementing what's almost certainly an illegal incarceration before trial. We'll have to keep checking to see how it turns out, and whether he can get restitution for the jail time.

In security-related situations, it's often a good idea to know the official published policy. When asked to violate it, it often can help to point out that what you're being asked to do is illegal, and ask if they really intended that. (If you're a contractor, you might try grinning and saying that you charge extra for illegal acts. Tell them that your consulting firm has a policy against performing illegal acts without first getting the explicit job description on paper with all the right signatures authorizing the higher rate, indemnification for possible charges, etc. It can be fun to watch their reaction.)

Noo you are completely wrong read the rules under which he worked below;

San Francisco government policy, from http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf [sfgov.org]

"Password Policy"
As such, all County employees (including contractors, vendors, and temporary staff with access to County systems) are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords.
All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed on at least a monthly basis"
"Do not share County passwords with anyone, including administrative assistants or secretaries.

All passwords are to be treated as sensitive, confidential County information.

Here is a list of things to avoid
-Telling your boss your password.
-Talking about a password in front of others.
-Telling your co-workers your password while on vacation."

SO it would have been illegal to do as you say.

Way to repeat your untrue accusation.

To repeat a poster above, whom you obviously did not read;

San Francisco government policy, from http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf [sfgov.org]

"Password Policy"
As such, all County employees (including contractors, vendors, and temporary staff with access to County systems) are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords.
All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed on at least a monthly basis"
"Do not share County passwords with anyone, including administrative assistants or secretaries.

All passwords are to be treated as sensitive, confidential County information.

Here is a list of things to avoid
-Telling your boss your password.
-Talking about a password in front of others.
-Telling your co-workers your password while on vacation."

Understand? He obeyed the law!

How do we know that he doesn't have a security scheme in place in case of death? For all we know he may have a section in his will dedicated to just that.

And at what point does it become okay to open those papers you mention? Is he ten minutes late and his cell phone is dead, but you really want to fix something? On vacation and you really want to fix this now and not wait until he gets back? He needs to stay in the hospital for a few days? Family emergency on the other side of the country?

In fact the password policy for San Francisco [57 page pdf] states the following:

If you must [write] your passwords down, store them is a secure place and never anywhere in your office.

Great - he's now stored his password in a sealed envelope and he's storing it in a bank vault with instructions left with the bank that in case of death or serious injury they are to hand over the letter to his supervisor.

That's definitely a secure location. Do we know that this isn't the case?

Wrong.

San Francisco official password policy

"Password Policy"
As such, all County employees (including contractors, vendors, and temporary staff with access to County systems) are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords.
All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed on at least a monthly basis"
"Do not share County passwords with anyone, including administrative assistants or secretaries.

All passwords are to be treated as sensitive, confidential County information.

Here is a list of things to avoid
-Telling your boss your password.
-Talking about a password in front of others.
-Telling your co-workers your passwordwhile on vacation."

http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

Which requires them to know what all of the equipment is, and potentially all of the software installed in all of it. Information for which Childs was supposed to be the source.

I'm not saying that the $5 million bail is right, but it's not at all inconceivable that Childs could cause damage to that network if he chose to do so.

Childs should not be the "source" of knowledge on their equipment. Their internal inventory and documentation policies are the source for that information. Childs designed and maintained the network, he did document it, even going so far as to Copyright the network design. Childs even followed policy when he refused to disclose his password to members of the San Francisco Police Department, representatives from HR, and an unknown group of people on the phone.

San Francisco government policy, from http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf

"Password Policy"
As such, all County employees (including contractors, vendors, and temporary staff with access to County systems) are responsible for taking the appropriate steps, as outlined below, to select and secure their passwords.
All system-level passwords (e.g., root, enable, NT admin, application administration accounts, etc.) must be changed on at least a monthly basis"
"Do not share County passwords with anyone, including administrative assistants or secretaries.

All passwords are to be treated as sensitive, confidential County information.

Here is a list of things to avoid
-Telling your boss your password.
-Talking about a password in front of others.
-Telling your co-workers your password while on vacation."

This is a corrupt government using its influence over the DA and judicial appointees to persecute Mr. Childs. After this last charge is throw out, Mr. Childs will undoubtedly counter-sue in a different jurisdiction to stay clear of the corruption in the SF government.

i did not know about this case so i went up looking back to all the story and trying to figure out what happened i've runned across these two that explain a bit http://www.infoworld.com/d/adventures-in-it/why-san-franciscos-network-admin-went-rogue-286?page=0,0 http://www.infoworld.com/d/data-management/childs-attempt-protect-network-password-gone-awry-978 What i'm now missing is what were his duties in the contract and who he had to provide those passwords. this document http://www.sfgov.org/site/uploadedfiles/dtis/coit/Policies_Forms/CCISDA_security.pdf cited in some post here is only about personal passwords and not system ones. So a sysadmin keeps an eye on security, he's asked by his boss in front of unauthorized people to reveal those passwords, in a improvised meeting in a place outside the place where he works. he refuse to say those passwords, he's suspended for unsubordination and some days later he's arrested, and he's still in prison He can only be guilt of being an asshole or too paranoid but since he was the only one responsible for the whole SF Wan who wouldn't have been ? you really would have give away your passwords knowing that if the day after the network would have been down it would have been your only responsability ? - "B....bbbut i gave the password to my boss!" - "Nice work! now you are fired and you'll be charged for the problem you caused with your inefficency" no really.. this story is crazy i really hope he will be released soon but then what about his lost job ? what about the loss in credibility he has to suffer due to ignorance of news that portrayed him as digital version of bin laden ?

Begging your indulgence, this is gonna be a little long but it's history. So, if you are looking for the nutz and boltz, here it is.

Here in SF after the fall of the Earthlink/Google WiFi debacle with the Mayor against the entire professional tech community, citizens and city government, the city's IT department contacted a bunch of us for some pizza and cola over many meetings. They had no idea what to do next. This was exclusive of the Mayor as they knew he really doesn't get it.

Our proposal that was heard consistently over the course of the whole controversy was finally taken seriously after three years. The whole proposal was to expand the existing 40+ mile fiber ring in the city to fiber-to-the-premises.

Now that we had their ear, we gave them the salient solution; split the baby.

The Mayor started out with the right premise, close the digital divide and create digital inclusion. But, the Mayor wanted more. He wanted all the photo-ops, glitter with the big tech boys and the worldly promotion in preparation for a run for governor. He should have stuck with the original premise. Serving the people and not himself. Why?

In progressive SF (not the other half), it is well known there is a seriously marginalized population of the people. Those children and families who cannot afford Internet access, no less, computers for that matter. Getting these folks Internet access and resources is essential to equalize the disparity and inequality. Once done, then everyone will be at the same level. Then the city can move ahead all together at once towards better and wider access.

Also on a technical note, there was no way their WiFi-only plan was going to work which resulted in the demise of Earthlink's national efforts in many cities. San Francisco's topology and weather conditions does not make for good WiFi. Plus, with fiber having ben around for nearly two decades as a viable technology, the back-haul needs to be in fiber and not wireless. It's just plain science as radio and network professionals who make up the core of the citizen's representation in this effort for over three years have been hammering into public officials. The Mayor did everything possible to not have to have the word 'fiber' be uttered so as not to compete with his WiFi plans. But the stories about the city's fiber network is now very well publicized. You can read the basic information here. For more information contact me.

Our proposal was for the city to continue their efforts to bring hardware, software, training, technology centers and resources exclusive of Internet access to the underrepresented community which amounted to about 75,000 people in households a little less than half that number.

"So, let's start there," we said. Bring fiber to every low-income housing facility along the fiber ring and light-up (pun intended) the whole thing. Getting on-site hardware would be a contribution of local businesses and non-profits. Pretty cheap considering (about $3500 each location). Then move onto the next and the next location.

So far there are three major housing locations that now have or soon to get light-speed access and the rest are in the hopper.

Now, what does this all have to do with education. Everything! The second half of our proposal is to proliferate out to the rest of the city. The problem is that there are rights-of-way that the city has given away over the decades. These contracts are extensively for a very long time. So, there is no way to take them back without great cost and legal trouble. So, then what?

While the city has all the resources ready, the school district has none. They are still using expensive T-1's where the copper is getting quite worn down being nearly 100 years old. But, the school district is the largest property owner in the city with over 100 locations that could be used as fiber nodes that can be branched out to surrounding neighborhoods plus offer a solid WiFi hotspo

Friggin' silly example.

If you have got an election with only three eligible voters and five candidates, of course things get messed up. And then you got a weird ranking system, too.

The multiple candidates model that I've seen (I believed they use it for some local elections in San Francisco) would do an instant runoff, like this: First tally the first hand picks. If there's no candidate with more than 50%, the one who got the least gets removed. Now, count the first hand votes again. Repeat procedure until one candidate with more than 50% is found.

Al wins the election right away, since he is the first hand pick of 2/3 of the voting population, no matter how many Daves and Eds are added to the lists.

Very elegant - it means that you can put your favorite guy first, the one where you'd be afraid to "waste your vote" on, and then put someone more "electable" further down on the list.

More here:

http://www.sfgov.org/site/election_page.asp?id=242 69

There does not seem to be a clear comprehensive policy, but the general tone is the same:

Don't hesitate to call 911. The 911 system was created to make it easy to request police, fire or medical response.
http://www.ci.bloomington.mn.us/cityhall/dept/poli ce/emerman/911.htm

If the public safety situation seems urgent and has the potential of escalating by not making the telephone call, call 9-1-1. The 9-1-1 professional will determine whether the call should be processed via 9-1-1, or whether the caller should be referred to another number or agency as appropriate.
http://www.sfgov.org/site/ecd_index.asp?id=14063

Any activity that seems unusual for your neighbourhood during the day or the night.
http://www.city.vancouver.bc.ca/police/blockwatch/ whentocall.htm

From those, and many more - it seems like anytime the presence of an officer is required in a timely fashion, calling 911 would be appropriate. Tresspass, especially criminal trespass and not just civil tresspass (which maybe the only kind of tresspass in some states) probably qualifies as needing an officer to respond.

Here's the SF Muni WiFi site

http://www.sfgov.org/site/tech_connect_page.asp?id =33899

if you read the Answers to Written Questions submitted by Sept 7th doc, you'll see that the city is not really interested in using wifi to it's full potential.

52. Q. Does the City plan to use TechConnect as a _primary infrastructure_ for Emergency/Disaster Service?

A. The City anticipates using TechConnect as one network to provide service in an emergency situation. The City does not plan to rely on a single technology, network or service for emergency/disaster service.

They have no SLA's that require the network to last after a disaster with redundancy, batteries, alternative power etc It seems, they narrowly changed the question and gave an elogated answer because they want free wifi from Google rather than holding out for a better overall city solution.

We need to find ways to allow real public participation in the creation of the wifi network for the city. Particularly one that works right after our inevitable earthquake.

Right now the city is taking Comments through end of September, but it is starting to seem they have already decided to go with whatever Google offers.

The SF approach to public comment is pretty lame - blind email only - please encourage them to get into the 21st century with e-rulemaking technologies to help create the best SF Muni RFP. Also encourage the committee to post electronically all the RFI/RFC submittals - since some groups may try to avoid publicity by submitting them only on paper.

A sample wonderful e-rulemaking site:

http://dotank.nyls.edu/projects/ERulemaking/sys_in dex.pl

Here's some great ways we could use technology and smartmobs ideas to improve the city response

http://www.stephensonstrategies.com/

Send your email comments requesting more open public participation and real support for disaster recovery wifi to the following:

TechConnect Information Line: (415) 554-5008

Email: techconnect@sfgov.org

Board of Supervisors:

http://www.sfgov.org/site/bdsupvrs_index.asp?id=72 71 particularly:

tom.ammiano@sfgov.org who as been an advocate of SF Wifi and

Ross.Mirkarimi@sfgov.org

Mayor:

Telephone: (415) 554-6141

Email: gavin.newsom@sfgov.org

SF Office of Emergency Services

http://www.sfgov.org/site/oes_index.asp?id=1399

ANN.STANGBY@SFGOV.ORG (Disaster planning Chief)

Here's the SF Muni WiFi site

http://www.sfgov.org/site/tech_connect_page.asp?id =33899

if you read the Answers to Written Questions submitted by Sept 7th doc, you'll see that the city is not really interested in using wifi to it's full potential.

52. Q. Does the City plan to use TechConnect as a _primary infrastructure_ for Emergency/Disaster Service?

A. The City anticipates using TechConnect as one network to provide service in an emergency situation. The City does not plan to rely on a single technology, network or service for emergency/disaster service.

They have no SLA's that require the network to last after a disaster with redundancy, batteries, alternative power etc It seems, they narrowly changed the question and gave an elogated answer because they want free wifi from Google rather than holding out for a better overall city solution.

We need to find ways to allow real public participation in the creation of the wifi network for the city. Particularly one that works right after our inevitable earthquake.

Right now the city is taking Comments through end of September, but it is starting to seem they have already decided to go with whatever Google offers.

The SF approach to public comment is pretty lame - blind email only - please encourage them to get into the 21st century with e-rulemaking technologies to help create the best SF Muni RFP. Also encourage the committee to post electronically all the RFI/RFC submittals - since some groups may try to avoid publicity by submitting them only on paper.

A sample wonderful e-rulemaking site:

http://dotank.nyls.edu/projects/ERulemaking/sys_in dex.pl

Here's some great ways we could use technology and smartmobs ideas to improve the city response

http://www.stephensonstrategies.com/

Send your email comments requesting more open public participation and real support for disaster recovery wifi to the following:

TechConnect Information Line: (415) 554-5008

Email: techconnect@sfgov.org

Board of Supervisors:

http://www.sfgov.org/site/bdsupvrs_index.asp?id=72 71 particularly:

tom.ammiano@sfgov.org who as been an advocate of SF Wifi and

Ross.Mirkarimi@sfgov.org

Mayor:

Telephone: (415) 554-6141

Email: gavin.newsom@sfgov.org

SF Office of Emergency Services

http://www.sfgov.org/site/oes_index.asp?id=1399

ANN.STANGBY@SFGOV.ORG (Disaster planning Chief)

Here's the SF Muni WiFi site

http://www.sfgov.org/site/tech_connect_page.asp?id =33899

if you read the Answers to Written Questions submitted by Sept 7th doc, you'll see that the city is not really interested in using wifi to it's full potential.

52. Q. Does the City plan to use TechConnect as a _primary infrastructure_ for Emergency/Disaster Service?

A. The City anticipates using TechConnect as one network to provide service in an emergency situation. The City does not plan to rely on a single technology, network or service for emergency/disaster service.

They have no SLA's that require the network to last after a disaster with redundancy, batteries, alternative power etc It seems, they narrowly changed the question and gave an elogated answer because they want free wifi from Google rather than holding out for a better overall city solution.

We need to find ways to allow real public participation in the creation of the wifi network for the city. Particularly one that works right after our inevitable earthquake.

Right now the city is taking Comments through end of September, but it is starting to seem they have already decided to go with whatever Google offers.

The SF approach to public comment is pretty lame - blind email only - please encourage them to get into the 21st century with e-rulemaking technologies to help create the best SF Muni RFP. Also encourage the committee to post electronically all the RFI/RFC submittals - since some groups may try to avoid publicity by submitting them only on paper.

A sample wonderful e-rulemaking site:

http://dotank.nyls.edu/projects/ERulemaking/sys_in dex.pl

Here's some great ways we could use technology and smartmobs ideas to improve the city response

http://www.stephensonstrategies.com/

Send your email comments requesting more open public participation and real support for disaster recovery wifi to the following:

TechConnect Information Line: (415) 554-5008

Email: techconnect@sfgov.org

Board of Supervisors:

http://www.sfgov.org/site/bdsupvrs_index.asp?id=72 71 particularly:

tom.ammiano@sfgov.org who as been an advocate of SF Wifi and

Ross.Mirkarimi@sfgov.org

Mayor:

Telephone: (415) 554-6141

Email: gavin.newsom@sfgov.org

SF Office of Emergency Services

http://www.sfgov.org/site/oes_index.asp?id=1399

ANN.STANGBY@SFGOV.ORG (Disaster planning Chief)

Companies like AOL and other dial-up or broadband types should start thinking about alternative methods for bringing in revenue, because their market is quickly diminishing.