Google restricting internet access to some employees for security
cnbc.com
cnbc.com
Fair. The higher the profile you have, the worse and the more numerous the attacks.
I found after creating a LinkedIn account, attacks went up on my account 12x. Again, caveat emptor... but this makes a great deal of sense in who to target. When you willingly put "I am Gee Golly Whillikers, Sr Systems Engineer of Really Important Systems that 10m people use", well... you're self-selecting who to hit.
> The company has also in recent months been striving harder to contain leaks.
Wait WHAT? That's what we cybersec folks call an "Insider Threat". "Leaks" are done by insider employees wishing to harm the org they work for, up to leaking classified data, or secret corporate data.
This is a WHOLE DIFFERENT REALM of attacks, and relevant appropriate defense. And this is how you get SCIF's https://en.wikipedia.org/wiki/Sensitive_compartmented_inform...
Recent news headlines from a cursory search:
Massive Leak Of ChatGPT Credentials (June 2023)
Far Cry's Source Code Has Leaked All Over The Internet (July 2023)
VirusTotal leaked data of 5,600 registered users (6 hours ago)
Pikmin 4 ROM leaks online (14 hours ago)
Wow, I was expecting to find a few examples of different kinds from the past year, not... several from today.I'm curious to know more about what you're doing to quantify this as an individual–I think I have a fairly sophisticated personal security posture and have implemented various business infosec measures professionally, but I'm not sure I have a great way of measuring how many attacks are targeted at me day to day, beyond a sort of vague sense of "this month I'm noticing more {frequent|targeted|sophisticated} attention".
Prior to using my email, I was getting 2 targeted attacks per week to my email.
After making an acct on LinkedIn with resume, was seeing 25-30 attacks per week.
I didn't make any attempt to determine the classification of attack, or its complexity. It was a simple dumb count.
The one that almost caught me was a simple email allegedly from the CEO asking if I had a minute. I was working at a small enough company that it wouldn’t be out of the question for the CEO to email me and I replied, sure.
The next email was, fortunately, a clumsy attempt at fraud, asking me to buy some Xbox gift cards for a client, which made me look a little closer and notice that the email address hidden by the email client behind the CEO’s name was at a Russian ISP, so I dumped them into spam and posted a warning on Slack. Something less clumsily targeted might have caught someone (e.g., to do a test booking on our site, or open some tech window). That said, LinkedIn is useful enough to me that I’m willing to leave that window open, although it would be nice if company email addresses were less easily guessed.
It's really on you for not checking the email instead of replying to basically a horny single in your area that could maybe give you a promotion.
As it's the part that can be authenticated (DKIM etc) a stronger word than "idiotically" is also appropriate.
Only signed emails can be authenticated against the sender.
Now - setting up SPF, DMARC, ... is technically easy but not so much organizationally. This is a real pain in the ass to find what various organizations used in the past in their outsourced communication (marketing, pay system, travel, ...).
The advantage that Outlook had (and has) is that it will resolve the user information from Active Directory. Receiving an email in Microsoft from "Bill Gates <helloworld@kjshkjsdhfkj.com>" will yield a very unusual visual (not the right firstname/lastname sequence, no picture, ...).
1. buy a cheap VPS ($5)
2. Buy a domain name with homoglyph unicode similar to the company's name
3. get a full stack of ssl from letsencrypt for the attack domain
4. set up postfix to use this domain with SPF/DKIM/DMARC
I then sent emails as the "CEO" and got by every spam and anti-impersonation filter. Outlook showed my emails as 100% legit in all ways. The ONLY way to tell was to go to email->properties->headers and KNOW and check the IP addresses of the servers.Homoglyphs in Outlook desktop app are not shown as punycode. However the users who used OWA saw the punycode expansion of the domain and rightly reported them.
Pretending I work for asdf.com, I could register аsdf.com (Cyrillic а) and maybe αsdf.com (Greek α) as a precaution.
But "xn--sdf-5cd.com" and "xn--sdf-nxc.com" both show as unavailable for registration.
Something like asclf.com (all ASCII) could be mistaken in some circumstances.
Incidentally, accidental disclosures are the main thing SCIFs are designed to prevent. Deliberately taking classified data out of a SCIF is not particularly difficult (although it is harder to plead accident if you are caught, which acts as a dissinsentive).
This isn’t always the main motivation, and in my experience this isn’t even usually the main motivation.
(But if I’m wrong, please tell me. Don’t downvote me for my opinion/life experience. I have definitely seen the whole “f the company” scenario a number of times. But usually it’s “f a particular person” or it’s a “this violates my principles” kind of thing. Companies are legally entities but not that much psychologically, in my opinion.)
It’s a “oops, I’m drunk or forgetful and said or did more than I should have” lol.
I forgot to add that one.
> Companies are legally entities but not that much psychologically.
This is my own statement that I can’t edit. I understand that many people think otherwise depending on the context. I do also. In this particular context of “insider threat” (i.e. employee leaks), I still believe the main cause isn’t to “harm a company”.
Perhaps a follow-up program ends up with a Qubes-like configuration, or just separate systems.
On the one hand, I agree. SWIFT recommend (in a similar vein) that machines that you do SWIFT tasks with are segregated from your daily driver last time I read the SWIFT standards; Microsoft recommend locked-down, no-access machines for a lot of AD admin tasks. If you do work in "I can tank a bank" roles, this will sound familiar.
On the other hand, this will also lead to cargo-cult "but Google programmers don't need Internet access, why do you?"
On the gripping hand, perhaps a bunch of Google people being restricted this way will lead to an resurgence in development and documentation practises that don't assume that you can download crap from the Internet all the time. That would be nice.
There's internal sites for searching, documentation, code, forums, newsletters, Questions/Answers, chat, calendar, video conferencing, browsing memes, looking at cat pictures and probably more.
Just a random thought: this coincides with the rollout of Bard. Perhaps the idea is that Bard (or its internal equivalent) is a suitable replacement for sites like StackOverflow?
To which the obvious reply is, Google already has the whole Internet cached and indexed. If they need to Google something they are only accessing the intranet.
They're probably allowed to use separate devices (i.e. sans corporate credentials) to access the outside web when they need to look up specs, SO questions, etc. This is just about air gapping critical systems.
I really have no idea why this is even a news item worth reporting, and jumping at the opportunity to criticize Google for this is a bit of a knee jerk HN reaction imo.
*: Just a feeling. I have no proof. Just speculating. Take it with a huge grain of salt.
As for how beyondcorp protects if a employee workstation does get owned: the zero trust means simply being within a network permimeter does not grant access... But employee workstations are trusted to do whatever that employee is authorized to do. So beyondcorp massively reduces what an attacker can do and adds lots of hurdles (e.g. requiring pressing a security key, pervasive monitoring), but doesn't render a hacked employee workstation harmless
It still sounds miles better than the traditional IT hell that is trying to constrain the devices as much as possible instead of securing the network and implementing auth internally.
Googlers by default, though, aren’t allowed to run vms (VMware/virtualbox style) on their desktops/workstations.
there's something to be said for building and running tests in the same environment your service targets. that's usually not going to be macOS or your favorite linux distro.
All the problems that you’re talking about of keeping in sync etc are just non existent. You have root directory /google/ and magic happens there. Look up articles about srcfs, objfs, piper, forge.
I honestly was looking if something exists open source so I can set it up at least for code editing, but all that I saw is just shit. When I compile at Google even using local build everything just works. Code on nfs network share + cachefilesd + all suggested flags for performance, with share at home nas (diskstation) on 1gbps lan + cachefilesd - constant issues like permissions. Simple test of cloning abseil library to that share and building takes 50%-80% more time than building locally.
Same test with qmk firmware spice is just unbearable. Even just doing git clone there is awful due to lots of small files, I guess. Tried cifs - also bad.
They work great in the (strong-internet availability) environments I've used them.
Also, as an ex-googler, I can attest that google's implementation was enough that I never missed local development.
This works great and is basically identical to working on my laptop directly except that my terminal is running over ssh rather than locally.
I love the idea of a powerful remote development machine but I’ve yet to find a tolerable RDP/VNC-type connection, and that leaves either something browser-based (VS Code maybe?) or something like JetBrains’ remote development tools which aren’t quite there yet.
I was speaking about VMware workstation, virtualbox and others. Running them is (was) not allowed
Needless to say none of the computers in the scif has internet. Keeping them updated was surprisingly simple - we could bring updates in, we just had an increasing stack of USB drives and hdds that never left lol.
What the handcuffs were for?
In BigCo land there are multiple attack vectors to the top execs.
I was literally in a convo today where our CFO and his EA are now virtually unreachable due to this type of stuff. Our IT team gave everyone burner phones above a certain grade level.
Strange days!
it's a pilot program..
The reason for the pilot is to study dynamics in play before rolling out a general policy, or to assess the feasibility of scaling up a program.
This is standard operating procedure in the corporate world, and isn't unique to tech-bros or FAANG.
What they are doing is called a "firewall", we have been doing that for a few decades now.
I even use a firewall at home !
That's because smart people tend to overestimate their abilities and think they are invincible. In fact the comment posted just below this one is jumping to conclusions that this probably only applies to the inferior-intellect mechanical and electrical engineers.
Did they _ever_ had root access in the last, I don't know, ten years?
Every tech company I've ever worked at, normal devs have had administrator access on their own Mac or Linux workstations, its only usually the sales/product folks who have locked down Windows machines.
And most SRE folks have sudo access on production VMs too
and regarding production, pure root access was revoked for everyone YEARS ago and replaced w/user and admin role accounts. admin was severely restricted, and could do most (but not all) things that root could do. this was for a server only, not accessing anything in borg/omega.
also, if a rando package was installed on a prod server there are safeguards in place that would detect a change and wipe it immediately. in my time that was called the 'assimilator'.
i'm sure that a very, very select few have actual root/sudo.
(disclaimer: i worked there 03-11, the role accounts were rolled out in 08 or 09 IIRC. things could be different now, and if so probably even more restrictive)
In the real world, endpoint security is very much a thing, and that means workstations so locked down, you can't even change the screensaver, let alone install unauthorized software.
If you work in health, for all intents and purposes you must be HITRUST compliant, and that basically mandates all sorts of lockdowns and network restrictions. ANYTHING that touches PHI must be airgapped.
I've been in the software industry since 1989 and I've never worked at a single company that didn't let developers have root/admin on their own PCs. "The real world" is quite a varied place.
You could also just do all of your development with fake PHI, but I've learned not to tell health people what to do.
Yeah, software companies like Google also lock user private data like crazy. But you can have root access (or at least you could when I worked there), cause for 99% of development, you couldn't touch actual user data anyway.
It really makes the most sense to grant employees the least amount of access possible for them to do their jobs. Anything else is courting unnecessary risk.
In most orgs, you'll see Windows and the sysadmins and devs will have LOCAL\administrator, but not LOCAL\SYSTEM. That's usually because developing software(debuggers) or using sysadmin tools is a admin-only thing.
As for me, I do prefer Linux on the desktop proper, with appropriate sudo access for root access. But again, I also do want SELinux on as enforcing, and fapolicyd enabled with good setup. If it's a laptop, I definitely want clevis and tang for enforcing attested and encrypted drives. If my shit is stolen, I dont want to be the vector where everything is stolen.
I've only been at one such place. At Google the desktops mostly run Linux, and you pretty much only get another option if you're actually working on stuff that needs it.