Live data from Hacker News

Elon Musk emails employees about 'extensive and damaging sabotage' by employee

cnbc.com

551–560 of 627 posts

Re: Elon Musk emails employees about 'extensive and damaging sabotage' by employee

#551
post #324

Earlier quoted context omitted.

He's pointing that calling someone a conspiracy theorist is an example of an ad hominem attack. Which it is and was and always will be. Calling someone a conspiracy theorist is talking about a person, not the ideas they are expressing. According to Paul Graham in his article How to Disagree an ad hominem attack is the second weakest form of disagreement, only a little better than calling someone mean names. However,…

Not exactly. Calling someone a "conspiracy theorist" can certainly be an ad hominem attack akin to calling someone a "wacko", but it can also be shorthand for "your argument is structured like a conspiracy theory", and conspiracy theories tend to be logically unsound because they are unfalsifiable. (Broadly speaking, the conspiracy theorist can always explain away evidence contrary to their claims by suggesting that…

Good point, though I'm really just trying to get across that 'since some conspiracy theories have turned out to be true, all conspiracy theories are likely true' is not a good summation of the motivations which produced rplst8 statement. When I apply the principle of charity to what rplst8 said, I'm forced to ascribe to him beliefs which maximize the correctness of his views. In doing so, I have to take the position that he is referring to conspiracy theorist as applied as a label to a person, rather than used as shorthand to discuss the structure of someone's argument. This is especially a truth maximizing necessity, because the conversation he is replying to is discussing cases where conspiracy theories turned out to be true; not just unfalsifiable rhetoric.

Re: Elon Musk emails employees about 'extensive and damaging sabotage' by employee

#552
post #475

Earlier quoted context omitted.

You can manage people and organize access without actually having the ability to gain access to their credentials. In fact, that's how it's supposed to work in safety-critical environments.

This is how it works in normal software companies too. I never see the credentials for my employees.

My point is, as a manager one can request that their subordinates get credentials to access systems. Therefore as a manager you could create a fictitious person (or use one that's recently left the company), and have them be given credentials to access those systems. Then you could use that fictional identity to do whatever nefarious things you want to do.

Then again it could be just as simple to create an alternate fictitious identity without going through IT but just by accessing the systems you have permission to access anyway.

Re: Elon Musk emails employees about 'extensive and damaging sabotage' by employee

#553

Earlier quoted context omitted.

I wrote the policy for our company (and got it through the audit and compliance processes, including SOX404 and PCI-DSS) that specifically and intentionally allows a specific group to take whatever action they determine is appropriate in the face of a production emergency, provided they declared the emergency, their intent, and documented/published what they did afterwards. I believe this policy, used only a few time…

This is great, thank you. Are you able to say what company you work for?

Sure. It’s Cimpress, the parent company of Vistaprint (the policy was authored when we were “just” Vistaprint).

Re: Elon Musk emails employees about 'extensive and damaging sabotage' by employee

#554

I made this same comment on the other discussion. I find it concerning that one person was able to push malicious code to 'production'. To me, this suggests that Tesla, a company building highly sensitive software, does not employ basic branch policies. How is is it that these changes could have made it through a code review process and get deployed? If a company like Microsoft or Google announced that a disgruntled…

Because it wasn't code pushed out to users. It was code pushed to the factory.

Codereview is a methodology to get high quality code you can stand behind and put your brand to.

Maverick engineers making hodgepodge changes and knocking things together quickly with no oversight is the way you get a proof of concept prototype working fast.

For the factory, I take it they're still in (or have returned to) the latter methodology.

Re: Elon Musk emails employees about 'extensive and damaging sabotage' by employee

#555

I made this same comment on the other discussion. I find it concerning that one person was able to push malicious code to 'production'. To me, this suggests that Tesla, a company building highly sensitive software, does not employ basic branch policies. How is is it that these changes could have made it through a code review process and get deployed? If a company like Microsoft or Google announced that a disgruntled…

At the very least you would expect these images to be signed. There's no way code should be injectable on the floor. The boot loader would simply not accept it. And you would expect any signed images to be code reviewed, regression tested, and system tested. Still, no way for sabotage on the floor.

Re: Elon Musk emails employees about 'extensive and damaging sabotage' by employee

#556
post #374

Earlier quoted context omitted.

Can you explain how Sarbanes-Oxley applies to the situation of an employee sabotaging a production line? Specifically how it would inherently imply wrongdoing on Tesla's part.

Basically, SOX would apply if the numbers Tesla announce in quarterly reports were derived from metrics taken from production-line systems. The wrongdoing is the same in every cause of SOX non-compliance: misleading investors to manipulate stock price. So Sarbanes-Oxley came about because Enron were stating investor-facing metrics that didn't match reality. SOX compliance comes about if you: * are publicly-listed * a…

I can confidently tell you that some of the largest companies in the world don't do this... Or at least don't do it to the level that an auditor could confidently say "nobody nefariously edited this code/data".

Re: Elon Musk emails employees about 'extensive and damaging sabotage' by employee

#557
post #511

Earlier quoted context omitted.

Part of Sarbanes-Oxley is to make sure IT systems are not manipulated. This includes regulating access to systems and controlling software development. Mainly this means, people who write code can't push code into production systems on their own. One person writes a requirement, this needs to be OKed by another person, then a third person writes this code and it's pushed to production. Controls are setup - e.g. check…

> Part of Sarbanes-Oxley is to make sure IT systems are not manipulated. I would expect that there are limits to this. If a rogue employee engages in fraudulent behaviour against you, using "false usernames" to subvert your security as this employee reportedly did, then I don't see how the organisation could be considered responsible.

I'm gonna guess they use github and this guy just pinged an admin to have a few new github users called things like "Legolas66" added to the organisation.

Many orgs don't track github usernames to real human mappings well or at all, mostly because the single sign on version of github is 3x the price.

Re: Elon Musk emails employees about 'extensive and damaging sabotage' by employee

#558

I have no problem believing that a disgruntled employee sabotaged part of the production line. But I do have a problem believing that all of the problems since the Model 3 started production were caused by sabotage. I also have no problem believing that the disgruntled employee simply wanted to take revenge by sabotaging his/her employer -- that's not uncommon, and it should not be difficult to prove if it really hap…

I think that he is probably playing up threats like that in order to distract from what appear to be systemic problems at Tesla.

But, to be blunt, I've seen what organized activists in the bay area are both willing and able to do, and so I'm not comfortable with writing off the idea of sabotage as _absolutely_ impossible

Re: Elon Musk emails employees about 'extensive and damaging sabotage' by employee

#559
post #339
post #84

Earlier quoted context omitted.

This is a very naive comment. There will always be a small handful of engineers that can push the button to move code into PROD or even change code in PROD live. Ideally, with mature controls, the people in this list is short. But to jump to the conclusion that Tesla doesn't use good practises is very short sighted. Who's to say that external parties didn't target this person specifically because of their role/influe…

Obviously, not all details are available, but the wording in the email suggests that the parent comment is anything but naive: > This included making direct code changes to the Tesla Manufacturing Operating System under false usernames and exporting large amounts of highly sensitive Tesla data to unknown third parties. This sounds like something out of the 1990s, that dark and romantic era of version control when we…

Every company I've worked at had a responsible person who was the only one able to push code into production. If you allow anyone to do that you are an idiot.

Re: Elon Musk emails employees about 'extensive and damaging sabotage' by employee

#560

I made this same comment on the other discussion. I find it concerning that one person was able to push malicious code to 'production'. To me, this suggests that Tesla, a company building highly sensitive software, does not employ basic branch policies. How is is it that these changes could have made it through a code review process and get deployed? If a company like Microsoft or Google announced that a disgruntled…

As the under-handed C contest ( http://www.underhanded-c.org/ ) demonstrates it's perfectly possible to write code that both looks innocent and apparently is innocent when run in a testing environment. You cannot produce a set of tests that show 'this code never causes anything bad to happen' so a sufficiently skilled malicious programmer could certainly write something that could cause issues that would pass stringe…

And even if they do lack review processes, it can't be said that putting in even the strictest of review procedures would stop a determined attacker.

It's almost childs play to hide a security vulnerability into a large 1000 line PR, down some error path, through a use after free, hidden deep in a library, a buffer overflow, a debug handler, or anything else really.

Post reply on HN