Live data from Hacker News

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

cnbc.com

401–410 of 627 posts

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

#401
post #304

Earlier quoted context omitted.

From my experience on the O365 team, it would have been difficult to push code without approval because it would have voilated a number of the compliance requirements that area of the business has to meet. But yeah, I suppose there are other areas of the company that might have more relaxed requirements

This doesn't sound like a technical control though?

You can enforce it on your git server. My experience is with Bitbucket but I'm sure Github has the same options. You could set up something like: nobody can push to master except through the PR UI, all PRs must have a reviewer, no PR can be merged to master without being approved by all reviewers. That way you guarantee that everything on master can be tracked to a dev + a reviewer giving sign off.

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

#402

Earlier quoted context omitted.

This is an absolutely vile personal attack. This is the poison contained in the blooming flower of the internet.

The poison of the internet thrives on 140 characters or less, it facilitates lies wonderfully. The truth needs more words. Twitter is Musk's preferred medium. Trump's too.

It's the Dalai Lama's preferred medium too. I don't really see your point.

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

#403
post #374

Earlier quoted context omitted.

"There will always be a small handful of engineers that can push the button to move code into PROD" I have very different experiences from a SEC regulated company. With SOX there are controls to prevent such a thing to happen. If this is a SOX breakage, Tesla is in deep trouble with the SEC.

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

  * announce numbers to investors
If those numbers are counted by a computer, you must show that you have procedures in place to prevent a single person from making a change to the code which would allow them to choose what number is produced.

So, if you were some web app that mentioned Monthly Active Users in your quarterly results: bam! Your release process now has to be SOX-compliant, since the MAU calculations come from analytics (from the frontend, or from access logs) which could be altered by some nefarious code.

Note that the intent of the act isn't to prevent such a thing from happening, but to make sure there is enough information for external auditors to detect it if it occurs.

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

#404

Earlier quoted context omitted.

> To me, this suggests that Tesla, a company building highly sensitive software, does not employ basic branch policies. Are they building highly sensitive software? I would suggest that the factory automation systems would be sensitive to downtime more than anything else, and the ability to respond quickly with changes would be very valuable. Merging policies would only slow this down. I would also suggest that there…

> Are they building highly sensitive software? A car is a potential murder weapon. So yes. Especially considering it may be remote-controlled, and deployed by the millions.

The national security implications are huge. The President should start a Car Force.

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

#405
post #29

Ahh, the little man again. The little man has been giving Elon and Tesla problems for a long time. Early on Musk thought Henry Fisker, who led the design on the Model S then left to start his own EV company was the little man, so he launched a lawsuit against him, but it turned out Henry wasn't the little man, and the lawsuit was meritless. The little man talked Musk into building falcon wing doors into the Model X,…

I honestly enjoyed this post a lot. It read like a silicon valley style children's book.

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

#406
Musk has every incentive to play up this incident, as long as it's concluded. A single bad event in the past can now be used to explain any number of problems. I trust him enough to believe there's a kernel of truth here, but the degree to which the sabotage actually affected operations is going to be presented in the greatest possible light.

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

#407

Earlier quoted context omitted.

Wow, I hadn’t heard of that - pretty horrible stuff. Thanks for the info.

I'm not trying to be mean here, but: you never wondered why so many people in Iran hated the US enough to call it the "Great Satan"? I know we've had a generation or so of leaders over here who just prattle on about "they hate us for our freedom", but I'm kind of boggled by the idea that people don't get curious and wonder what really set off the level of virulent hatred of the US (and European powers) that existed a…

I may be betraying ignorance (I always love to learn—thanks!), but before today, I assumed that had to do with the US being Israel’s closest ally, since Iran from the beginning has hated Israel for what I assumed were religious reasons, and the fact that a non-Islamic country has (parts of) Jerusalem after over 1000 years of wars over who gets to have it (many of which were at least partly religiously motivated — or at least that’s how it was spun to gain support).

That and an impression that Iran “wants to do bad things” (like human rights violations and irresponsible ownership of nuclear weapons), and doesn’t like world powers keeping those plans at bay.

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

#408
post #377

Earlier quoted context omitted.

There may have been. The article speaks of the employee using "false usernames". Code review may stop some foolish person pushing broken code, but it's not going to prevent a determined saboteur who's masquerading as other authorised users.

How the saboteur knew the passwords of all those users before? If it was a totally new user, shouldn't the system have a list of approved users and a strict protocol to validate a new user?

I'm baffled at your lack of imagination, but: keyloggers, unlocked terminals, API token sniffing from cookies, reactivated old accounts, changing the reviewing account id in the database, …

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

#409

Earlier quoted context omitted.

Not to nitpick because you are spot on but I think you need to go back to at least the D'Arcy Concession to understand the modern Middle East.

You could really write a couple doctoral theses just doing a review of the stuff necessary to understand contemporary middle-eastern conflicts and politics. I tried to pick a couple things as examples rather than write those theses :)

True. I only mentioned it because of it's significance in relation to the long running war over oil in the Middle East. The ME has however held importance as a trading route since the beginnings of what became the silk road.

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

#410

Earlier quoted context omitted.

I think you misunderstand. Even with code review policies, there is still a short list of people who can push to production without going through code review. Not from a policy standpoint but from a security and access perspective.

> Even with code review policies, there is still a short list of people who can push to production without going through code review. That's completely unnecessary and should not be the case. If you need something pushed quickly, you can get a colleague with review bit and get them to ack for "urgency" reasons after a quick lookover.

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 times per year, has saved us 8 figures in outage costs over a decade. (More than half of the benefit is from a clear statement and instilled sense of ownership, and only secondarily the defusing/unraveling of people would otherwise wait or insert tangles of “best practice” red tape while the website or a factory was hard down.)

I based it on 14 CFR 91.3 (in intent) which says, in part:

91.3 Responsibility and authority of the pilot in command.

(a) The pilot in command of an aircraft is directly responsible for, and is the final authority as to, the operation of that aircraft.

(b) In an in-flight emergency requiring immediate action, the pilot in command may deviate from any rule of this part to the extent required to meet that emergency.

(I made part c of the law, the reporting requirement, mandatory where it’s only on-demand in the aviation law.)

When we explain the policy to new employees, we often cite the aviation law directly, to help clearly communicate our intent.

[0] https://www.law.cornell.edu/cfr/text/14/91.3

Post reply on HN