491–500 of 627 posts
Perhaps they should have better security measures? If I understand correctly, Tesla cars can be updated OTA including critical functions, so someone who manages to insert a malicious software update might be able to kill everyone driving a Tesla at some moment, plus numerous bystanders.
Earlier quoted context omitted.
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, …
Earlier quoted context omitted.
> I find it concerning that one person was able to push malicious code to 'production'. Production line software is almost certainly handled separately from the software that runs their vehicles, and isn't "production" in the usual web sense of being customer facing. This sounds more like someone messed with their factory automation setup.
Are you trying to us that less stringent controls on manufacturing software is in any way acceptable? Manufacturing process (including mfg software tools) are a huge potential source of product failure. I don't know about automotive QMS specifically, but I work in embedded software for safety critical systems. If an unreleased procedure or unreleased software is used to build the hardware, or unreleased software is r…
It's not really comparable to your work where you're writing the OS or system code for a safety PLC or something, and you quite rightly have to maintain a very strict process where everything is fully documented and triple-checked so you can prove that it meets your target performance level. All of the stuff that does need that kind of precision is locked away into modules (like the aforementioned safety PLC) which just gets plugged together like Lego by most of the controls team.
(All this is kind of moot, though, because it says that the culprit used a few different logins to make their mischief. Depending on the permissions set for those logins they could have bypassed pretty much any formal workflow, at least temporarily.)
Earlier quoted context omitted.
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, …
"Hey Ed my password expired, can you use yours to get this done just now..."
Earlier quoted context omitted.
That's all good and nice but in most cases, this is a matter of policy. If someone actively tries to circumvent the policy or the process, odds are that most software shops would fall victim to the same thing. Especially in the case of internal software. Even if you have a system that attempts to enforce the process, odds are that the system isn't without flaw and is not too hard to circumvent. Most businesses who's…
> If someone actively tries to circumvent the policy or the process, odds are that most software shops would fall victim to the same thing. Too often the focus is entirely on outside attacks, with little consideration given to insider attacks. Previous job was at a cyber security firm. We'd routinely come under attack from criminal and, we believed, occasional nation state attacks as our researchers attributed a few…
Maybe not the most technical solution to this, but one of my previous employers had a workplace culture of setting the desktop background to a rainbow with unicorns if someone left their computer unlocked. Sometimes even teams of two would work together to pwn some of the more alert members, by temporarily keeping them distracted while the other "attacker" did the business.
3 or more fails and the background bumped up to something pretty gross that nobody wanted, simply as a practical matter.
I actually thought gamifying it made it pretty fun, and at least for workstation locking, we were elite. Even today I'm sharp about it. Maybe it could be extended to physical access to areas as well.
I'm sorry but Musk's email is ridiculous and unprofessional, and the defenses here are extremely concerning. By ArsTechnica's count this is the 5th fire in the plant. 5th. That's insane. Report after report is that things continue to not go well and the email sent out reeks of paranoia and combined with other comments made recently are quite clearly dishonest. They aren't failing at the details of ramping a manufactu…
> He said it was about promotion The saboteur said it was about promotion. Why would he lie?! /s
We only know what Musk said in his email.
Deal with the facts and context available - not what Elon wants you to infer from his implications while retaining plausible deniability.
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…
I have no idea what has happened at Tesla, it's perfectly possible they lack processes they really should have, but you cannot prove that from the information available.
Earlier quoted context omitted.
> 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 time…
Wow...I've lost all hope in HN. It's officially become worse than Reddit in terms of astroturfing. I don't know how you can take a story about someone inside Tesla sabotaging their operations and come out against Tesla in this situation, but somehow every single comment in this thread has manged to do that in different ways. "Tesla's fault for letting this happened!" "It's just an excuse for production delays!" "Elon…
It's dangerous to assume that everyone who disagrees with you on the internet is a bot.