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?
Elon Musk emails employees about 'extensive and damaging sabotage' by employee
401–410 of 627 posts
Re: Elon Musk emails employees about 'extensive and damaging sabotage' by employee
#402Earlier 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.
Re: Elon Musk emails employees about 'extensive and damaging sabotage' by employee
#403Earlier 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.
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
#404Earlier 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.
Re: Elon Musk emails employees about 'extensive and damaging sabotage' by employee
#405Ahh, 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,…
Re: Elon Musk emails employees about 'extensive and damaging sabotage' by employee
#406Re: Elon Musk emails employees about 'extensive and damaging sabotage' by employee
#407Earlier 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…
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
#408Earlier 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?
Re: Elon Musk emails employees about 'extensive and damaging sabotage' by employee
#409Earlier 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 :)
Re: Elon Musk emails employees about 'extensive and damaging sabotage' by employee
#410Earlier 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 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.