Reblogged:The Limitations of CYA

[Gus Van Horn blog]

Making the rounds on the internet is a storyabout a junior software developer who, on his first day on the job, got fired after he accidentally destroyed his company's production database. Commenters at Reddit (above) Hacker Newscorrectly flayed the executive who fired this sadder-but-wiser employee. A comment at the latter does a good job of summarizing why firing this employee was a bad idea:

Sorry, but if a junior dev can blow away your prod database by running a script on his _local_ dev environment while following your documentation, you have no one to blame but yourself. Why is your prod database even reachable from his local env? What does the rest of your security look like? Swiss cheese I bet.

The CTO further demonstrates his ineptitude by firing the junior dev. Apparently he never heard the famous IBM story, and will surely live to repeat his mistakes:

After an employee made a mistake that cost the company $10 million, he walked into the office of Tom Watson, the C.E.O., expecting to get fired. "Fire you?" Mr. Watson asked. "I just spent $10 million educating you." [italics in original]

Indeed, as business writer Suzanne Lucas notes, it is the CTO who should have been fired for this incident. As it stands, he has harmed a former employee and his employer. And with the attitude towards learning and responsibility his actions demonstrate, if the CTO remains employed, he will continue to be a major, hidden liability of unknown size for his company.

-- CAV

Link to Original

[Reidy]

The moral you draw is sound, but I'll at least have to see some names (the new hire, the CTO and the company) before I believe it.

[Nicky]

Quote

Sorry, but if a junior dev can blow away your prod database by running a script on his _local_ dev environment while following your documentation, you have no one to blame but yourself.

That's not how the guy's story goes. He is claiming that he was given some documentation (to help him set up a development environment for himself), and that documentation contained credentials to the production database...and that he inadvertently used those credentials, accessed that database, and did something (it's not clear what, he doesn't know) to it.

Quote

Why is your prod database even reachable from his local env? What does the rest of your security look like? Swiss cheese I bet.

It's reachable for the sake of convenience.

There's no imperative for a software company to protect its stuff from systems within the company, with anything more than a username/password. If it was a major bank, or some kind of critical infrastructure, sure, you have certain parts of the system behind locked doors, physically cut off from the rest. But this is just a software company. I can't imagine any small/medium software company would cut off access, from any workstation in their office, to any system/database.

You need credentials only key employees should have, of course, but, with those credentials, it makes sense for the db to be reachable from any workstation.

Edited June 7, 2017 by Nicky

[Nicky]

10 hours ago, Gus Van Horn blog said:

After an employee made a mistake that cost the company $10 million, he walked into the office of Tom Watson, the C.E.O., expecting to get fired. "Fire you?" Mr. Watson asked. "I just spent $10 million educating you." [italics in original]

So? Does that mean you should never fire anyone? We don't know how competent or incompetent this guy is. We don't even know the exact reason for the firing. We don't even know for sure that he's fired.

Just because he got hired doesn't mean he's competent. From the sound of it, the development team isn't the one doing the hiring at this company, it's the HR team. I've heard stories of HR teams doing a comical job of determining competence and ability, before hiring somebody.

It's perfectly plausible that this mistake wasn't the immediate cause of the firing, and instead just caused a deeper look into the decision to hire him.