Obviously not true, in fact none of the companies I worked in that was the case. Now, if we're talking about somebody like network admin that may be more juicy, but in a large company rarely a single person has the "highest possible level".
> If you never worked at a company that took it seriously it is hard to imagine that there are people who do take it seriously
This sounds quite unsufferably smug, and unwarrantedly so. Yes, we get it, in Google they have access levels. Newsflash: this concept wasn't invented by Google. A lot of companies use it. Running code on engineers workstation does not give you keys to the whole castle. But it does get you into a first perimeter, after which you can do some recon, not available outside the big firewall, launch other things against corporate sites not available to mere mortals, look for "experimental" servers which are poorly secured because they're not production yet and are behind corporate firewall (that happened in pretty much ever company I've worked with), get their hands on some juicy browser cookies containing authorizations to some internal services, steal some code finally... There are a lot of interesting things a person can do with engineer's access and some of them may land a stepping stone to a next step access maybe. If you don't understand why such a thing may be important even without giving somebody the keys to the castle - maybe you don't know enough about how secure systems are built to smugly dismiss other people.
Selection bias. In some companies access to an engineers single workstation allows access to potentially billions of dollars worth of intellectual property. Imagine China stealing the design for the latest aircraft engine from GE, or accessing the PC of the most senior accounts payable person in a company and getting access to actual money. Just because YOU weren't the most valuable target in a company doesn't mean no one in your role is. My account at my company is constantly under attack because I'm the VP of IT in healthcare. The reality is "my" account doesn't even have any powers, it's just email. My accounts with sensitive access are separate.
> People [..] freak out about this because [..] in 99.9% of companies, running code on an engineer's workstation would immediately be the highest possible level of breach.
So it's not selection bias, it's a counterargument. The poster also said engineer not "VP-level".
So, your comment is not really relevant.
I once offered a bet to the large security team at a well-known decacorn tech company I worked at: I offered to make a personal, reasonable-sized cash bet with any member of the security team that I would win if I could deploy malicious, unreviewed code to any service or machine of their choice without it being prevented or proactively noticed by them.
The members of the security team all declined my bet. We're talking about a team of probably at least a dozen people, many of who had been working at the company far longer than I and who had been shaping and reviewing the company's security design for years.
They knew perfectly well that I would be able to win the bet. Not because their security was unusually bad, but because it was bad in the common, usual ways. Securing the supply chain is hard, and real security is almost impossibly expensive to add to a system late in the game if you didn't design it in from the beginning.
It's fine to not be confident, but when professional security teams at large companies are afraid to express confidence that their systems are non-trivial for a random engineer to hack in their free time, that seems at odds with the claim that it's "obvious" that permission escalation is hard
A willingness to take pride in your work and to not take it too seriously when smart, well-intentioned people make mistakes (e.g. blameless postmortems) is part of the culture difference that led to Google's engineering becoming so exceptional and innovative vs the more corporate, don't-rock-the-boat, fear-driven culture that the traditional businesses had at the time.
I'm assuming you were at google in late 90s/early 2000s?
I've long thought that one should have the attitude (and act to make it so) that one should be willing to bet their job on the quality of their work, but not necessarily actually do so.
And betting anyone (co-worker or not) that they can't compromise the systems (especially, but not limited to production systems) you're tasked with keeping from compromise is a bad bet -- even if you win.
I'd class that sort of behavior as having serious potential to be a "Career Limiting Move" (CLM).
There is no big firewall to bypass here. That's the whole point of zero trust.
Also, about “code reviews”: here’s a story from last year about how a massive refactoring of some webkit code in 2016 resurrected a massive exploit that was actually fixed in 2013, but went unnoticed. It was only discovered and patched in 2022, as it was being exploited in the wild by, among others, the NSO group.
https://www.theregister.com/2022/06/21/apple-safari-zombie-e...
Even if you only take over one developer's system, it's a great starting point for pivoting into the network and starting a more sophisticated attack. I'm sure an advanced threat actor would know how to take advantage of the opportunity against Google.
We both know that Google does better than most at endpoint security. In some cases it’s possible to argue that they are the best. What we definitely don’t need is you to be superior about it: it’s part of the reason why (ex-)Googlers have a poor reputation.
In this case, having technical measures that avoid sensitive things ending up on developer machines is an excellent way to help improve your security posture. That said, it definitely doesn’t mean you shouldn’t be unconcerned about code execution on developer machines. There’s a reason that internal red team exercises distinguish between external access and already having a foothold on a machine.
In this case isn’t obviously not a specific failure in Google’s security policy that package managers don’t do namespacing, but if I was on the team and I received this report I would at least think about whether there is something I would want to do here to improve the situation, similar to existing efforts to prevent attacks like paste bracketing or trivial keylogging.
Seems weird to group those two as the same thing
tl;dr - if I were still gLinux security, I might not be freaking out about this, but it would definitely fall into the set of stuff I'd be making space for in next quarter's OKRs.
Haha I hope this to be true :sigh: The reality is that all those security hardening measures already surpass the level where it significantly undermines the overall productivity... Engineers cannot even have a test run on production data without an explicit review from colleagues.
Tools like code search and the source checkout process also both check for accessing unusually large portions of the codebase, making it only possible to exfiltrate small portions of the codebase at once.
https://github.com/google/santa
This is a product developed by Google that has at least been utilized internally to some extent. It's not perfect, but my previous company used it and it does prevent unexpected unknown code from running in the background.
What it does not do is prevent someone from intentionally downloading and executing a library unless the upvoter actually comes to some demand that you do so. I found that it quickly became a bit of a "alert fatigue" where you approve things your coworkers send you so they can get back to work without properly vetting.
In a well designed zero trust network this makes little difference. The traditional posix security model is bogus from the start anyway. A lot more useful stuff you can exfiltrate as a regular user usually.
So just like pretty much any package from public repo out there ?
(I work at Google but have no special insight. My opinions are my own.)
(Or, is this comment https://news.ycombinator.com/item?id=35585453 complete and accurate?)