Google Restricting Internet Access To Some Employees To Reduce Cyberattack Risk (cnbc.com) 58
Google is starting a new pilot program where some employees will be restricted to internet-free desktop PCs. From a report: The company originally selected more than 2,500 employees to participate, but after receiving feedback, the company revised the pilot to allow employees to opt out, as well as opening it up to volunteers. The company will disable internet access on the select desktops, with the exception of internal web-based tools and Google-owned websites like Google Drive and Gmail. Some workers who need the internet to do their job will get exceptions, the company stated in materials.
In addition, some employees will have no root access, meaning they won't be able to run administrative commands or do things like install software. Google is running the program to reduce the risk of cyberattacks, according to internal materials. "Googlers are frequent targets of attacks," one internal description viewed by CNBC stated. If a Google employee's device is compromised, the attackers may have access to user data and infrastructure code, which could result in a major incident and undermine user trust, the description added. Turning off most internet access ensures attackers cannot easily run arbitrary code remotely or grab data, the description explained.
In addition, some employees will have no root access, meaning they won't be able to run administrative commands or do things like install software. Google is running the program to reduce the risk of cyberattacks, according to internal materials. "Googlers are frequent targets of attacks," one internal description viewed by CNBC stated. If a Google employee's device is compromised, the attackers may have access to user data and infrastructure code, which could result in a major incident and undermine user trust, the description added. Turning off most internet access ensures attackers cannot easily run arbitrary code remotely or grab data, the description explained.
Say what? (Score:2)
I think someone is using AI to write these articles. That should read, "In addition, MOST employees will have no root access. . .
The only people who should have admin rights are programmers and IT staff. Everyone else gets locked down, including the folks at the top. There is no legitimate reason for the average person to have admin rights on a business machine.
Re:Say what? (Score:5, Insightful)
>The only people who should have admin rights are programmers and IT staff
That's usually a significant portion, if not the majority, of people in a software company.
Re: (Score:3)
I would say less than a quarter of Google's employees will fall into that category. You may not have an idea just how many support staff are needed in a company that large.
Re:Say what? (Score:4, Insightful)
"The only people who should have admin rights are programmers and IT staff"
And at that, only some IT staff should be root, and few programmers (application programmers do *not* need to be root).
Re: (Score:2)
I see applications all the time that fail without admin access, and I immediately know they were developed in an insecure environment.
I hate it, it's so stupid. Very few things should require admin access to RUN. To install, sure. To change some configuration items, possibly. But not to run. The problem is lazy devs and a lack of a whip-wielding overseer.
Re: (Score:3)
Why doesn't Google use their own solution? ChromeOS in a VM with VPN restricted to outside Internet. Then lock the main machine to the corporate network.
Re: (Score:2)
ChromeOS needs a lot of work before it becomes a useful VDI client.
I wish Google could work on this, because if they can make ChromeOS into something that isn't absurdly painful for VDI work, it would be quite useful, and gives businesses a lot more security options.
Re: (Score:2)
There's been some times back when doing Oracle DBA work that I needed root....I had a good relationship with my SA's and they gave me sudo root access.
I knew enough to be VERY careful when doing anything....and got in/out quickly when I needed it.
Turnaround to install a needed library (Score:2)
application programmers do *not* need to be root
When you are programming an application, and you need to install some tool or library on which the application depends, and you file a ticket requesting installation of the tool or library and its related header files on your development PC, how long does it usually take for the IT department to process this ticket?
IT need not apply (Score:1)
Re: (Score:2, Insightful)
Even programmers should generally not have root access to their main corporate workstation that is used for email and other internal tasks. There will usually be separate development machines for them to test code on. Test/dev machines should be isolated, and not contain any sensitive data aside from the code being actively worked on.
Same with IT staff, no need to have admin privileges on your local machine (it should really be a dumb terminal), and only on certain systems you are responsible for managing,
Re: (Score:2)
Re: (Score:2)
Can I suggest your attitude here is why we are still struggling to solve the same IT security problems that have been subject of most discussion for more than a decade now?
if IT staff don't have the ability to install software on a given computer, they're not going to use that computer for anything of consequence, certainly not for something that's as big of a time-sink as email can be. The problem is that a normal computer set up for a normal user, isn't really usable for us.
Why if its so bad you can't or won't use it, it can't really be 'good' for anyone else can it. Maybe you should be trying to fix that?
But you are different right - you don't ever run binaries from lower trust sources than what is in you general supply chain right? If you use FOSS tools or scripts you carefully audit all of them for RATs,
Re: (Score:1)
Can I suggest your attitude here is why we are still struggling to solve the same IT security problems that have been subject of most discussion for more than a decade now?
What discussion are you talking about exactly?
if IT staff don't have the ability to install software on a given computer, they're not going to use that computer for anything of consequence, certainly not for something that's as big of a time-sink as email can be. The problem is that a normal computer set up for a normal user, isn't really usable for us.
Why if its so bad you can't or won't use it, it can't really be 'good' for anyone else can it. Maybe you should be trying to fix that?
Why don't you go and fix that, instead of asking people who want to do their jobs efficiently to do the exact opposite – mucking about with pointless drivel for the sake of making some holier-than-thou infosec wannabe like you happy?
But you are different right - you don't ever run binaries from lower trust sources than what is in you general supply chain right? If you use FOSS tools or scripts you carefully audit all of them for RATs, backdoors, etc, don't you? I mean you saved so much time not using that 'normie setup'!
Personally I don't anything in Outlook anyone else in the company probably should not need or want to do. I don't run rando tool on my host system either - I don't want machine where I do basic office work fouled up and krufted up. I have VM for these things that does not get my account on corporate systems, if I need to authenticate something on the VM. I usually shut the VM down and roll my passwords.
I'll close this off with something people like you really need to read: https://kellyshortridge.com/bl... [kellyshortridge.com]
If you can see yourself in that text, maybe stop being a jerk and let people do their job for once.
Re: (Score:2)
Nope I don't see it. Actually I see someone in that, who I would not let near anything important. He clearly has worked with some bad security practitioners, which absolutely do exist and in large numbers. However he is really unimaginative when he gets into his whole business about "outcomes" and has no sense at all about the need to control blast radius _especially_ in today's environment of zero trust models and cloud deployments.
My point is security gateways and process need to be as low friction and
Re: (Score:1)
> Can I suggest your attitude here is why we are still struggling
> to solve the same IT security problems that have been
> subject of most discussion for more than a decade now?
You can suggest whatever you want. It doesn't change anything.
> Why if its so bad you can't or won't use it, it can't really be
> 'good' for anyone else can it.
This argument is entirely specious. Most users aren't trying to do the kinds of things that network administrators do, or anything in even remotely the same bal
programmers may need root to make images (Score:2)
programmers may need root to make images / debug code / install or update dev tools.
Re: (Score:3)
All of which should be done on a different machine not used for day to day corporate tasks...
Either multiple physical devices on an isolated network as needed, or remote access to dev boxes where you do have root.
Re: (Score:3)
When working remotely...yes you can and generally do ssh into your remote boxes.
But I've needed elevated prims on my local box to run some things locally to prepare things to scp over to the remote box.
While I agree there's not many use cases...there are some.
And not everywhere will give you m
Re: (Score:3)
Doing dev on a remote box sounds like a nightmare unless you solely code in vi.
Re: (Score:2)
Doing dev on a remote box sounds like a nightmare unless you solely code in vi.
Do you really think that people go into a datacenter to work on boxes? It's all remote. They only question is how far away.
Re: (Score:2)
Doing dev on a remote box sounds like a nightmare unless you solely code in vi.
Do you really think that people go into a datacenter to work on boxes? It's all remote. They only question is how far away.
Yeah, but no one codes the multi 100k line application that gets deployed to the data center remotely via a terminal. You code it locally on your dev machine, check it into source control, and your build system produces an artifact or code bundle that gets deployed. Remoting to the data center is for config tweaks or debugging, not development. Any day I find myself shelling into the data center by hand and touching files is going to be a bad day.
Re: (Score:1)
The same for internet access. Really should be a separate machine. But then again all their productivity tools should be on a separate internal network.
linux disrots need root or sudo admin for wifi (Score:2)
Linux distros need root or gui sudo admin for wifi. SUSE Linux needs ROOT password to join wifi networks.
Some even need it to install updates in GUI / desktop
Re: (Score:2)
Developers are some of the worst people to give elevated rights to.
IT encompasses so many roles that it's an ineffective solution to say IT should have admin rights.
Even when a user has elevated rights it should be through a separate account.
No shit ... (Score:2)
That's how most companies should run their IT. Internet browsers shouldn't be any closer to intranet access than behind a VM barrier, though the Cloudflare isolated browser works too.
Internet access on work computers (and by extension BYOD) were clearly completely retarded. Everyone was doing it wrong for half a century and now finally sanity is setting in ... took you guys long enough.
Re: (Score:1)
Just run ad blocker (Score:3)
People use ssh keys without passwords and re-use same ssh key for everything. In general convenience overrides all security considerations. That is why attacks succeed.
Re: (Score:2)
We should give everyone access to the nuclear launch codes. We'll just trust them to be smart enough not to use them. Sounds like a solid plan.
It should always have been restricted (Score:3)
Google should know better. Nobody should have admin access, not even those who actually need it... those people who need it should have a secondary account they invoke for admin tasks.
As for general Internet access, outside of a truly secure environment (where the computers should have anything not mandatory be prohibited) I find it best to point employees to an Internet usage policy and then let them have filtered access. Yes, every once in a while you have to slap somebody's wrist. It's better than treating everyone like they're on a chain gang.
Re: (Score:3)
Re: (Score:2)
The problem is the underlying security is weak - when the UAC pops up demanding your attention, it's because what you're trying to do can be useful to a malicious actor.
I admit it would be nice if you could authorise individual tasks permanently - say you like to fiddle with your network card properties or something. Rather than having to deal with entering your admin credentials each time, there should also be a checkbox for 'always allow on this account'. One and done.
I don't know from a coding perspect
need good self install software tools that bypass (Score:2)
need good self install software tools that bypass needing root / sudo needing to call the help desk for each software update takes to long.
Re: (Score:2)
>"As for general Internet access, outside of a truly secure environment (where the computers should have anything not mandatory be prohibited) I find it best to point employees to an Internet usage policy and then let them have filtered access. Yes, every once in a while you have to slap somebody's wrist. It's better than treating everyone like they're on a chain gang."
We have a whitelist with many hundreds of approved site domains that are used for general business. Lots of resource sites, our vendors,
Re: (Score:2)
Well you know...it's all that "move fast and break things" attitude in Silicon Valley
Seems ironic (Score:2)
That such a "cloud" and advertising company would choose to lock its own employees from the environment created by them reeks of irony.
Of course, the reality is we need aggressive steps beyond this for improved resiliency.
Re: (Score:1)
yes a cloud company says you shouldn't use the cloud to be safe! Never ever use Google Docs & Sheets
Re: Seems ironic (Score:2)
Localadmin for Devs (Score:2)
I have been on all sides of this issue. In a very large organization I was...
- The developer swearing up and down that admin access was absolutely necessary
- The team lead defending this viewpoint to his supervisor
- The supervisor being given "absolutely not" by the maturing security practice and discussing it with the team lead
- Part of the "focus group" considering the question from the security side
- The security auditor looking from the outside in
Over the years, the devs won the fight less and less freq
Re: Localadmin for Devs (Score:2)
Downloading unvetted things just to try them out is how things go sideways. A great many programmers don't see themselves as the risk that they are.
What halfway decent dev team doesnâ(TM)t set up a lab environment? Oh, lookâ¦an old VMWare server thatâ(TM)s gone out of serviceâ¦pop it onto a separate VLAN (or even better, a physically separate LAN) with limited access to the internet, etc.
Download and play all you want in your isolated sandbox. But your corporate laptop is locked down.
Re: (Score:2)
My killer argument was "if the computer illiterate boss secretary who spends more time on Facebook and Instagram than working has admin access to her crate, giving it to devs who do know the security implications can't make it worse".
It did get me some VERY nasty looks from the CEO, but you just don't fuck with your CISO if you know what's good for you.
Re: (Score:2)
I am a devops developer for a large insurance company. All desktops (laptops) are a single corporate image. Of course they don't have any tools like git. vscode, etc. I don't care what side you are on, the most economical solution to this is local admin rights.
We package all that software so that our developers are all running the same version with the same plug-ins and options. The product requirements and configurations are managed by a technical group that has representatives across the various developer groups.
My team provide 1st level vetting of all local admin accounts (normal accounts don't get admin rights ever, you get a special account) and anyone asking so they can install software is shutdown. Some software require local admin to run and those peopl
Re: (Score:2)
They are doing it wrong.
It's not for the reasons you think (Score:2)
Most companies have those policy anyway regarding admin access, and strong firewalls to restrict content and security risks. This no 'internet' access thing is something different I'm sure of it. It's more likely they have people not performing their duties properly and spending too much time doing X, and if they directly target X people will perceive it as being against X or try to distract it as that, so google doesn't want to restrict access to X or multiple sites that people are taking part in X, and is
Lemme get this straight (Score:2)
You exclude the two main attack vectors and think you're getting safer, right?
Data Point (Score:2)
I thought it was fairly common to have a locked-down workstation with no internet access for administration of critical systems. The term I know them as is "Privileged Administrative Workstations" or PAWs for short.
https://aka.ms/cyberpaw [aka.ms]
Re: Data Point (Score:2)
It is. This article is flamebait, and leaves out any kind of useful details.
I would say it is a flat out lie, but I am sure there is some small bit of truth to this article. What part is true is unclear.
LOL (Score:2)
The world's largest Internet company scared of the Internet. Proof that the impending implosion is near.
Google employees also have a laptop (Score:2)
It sounds like it's just their development desktop PC that's being locked down. If they need to access things like Stack Overflow they can probably use their laptop.
BeyondCorp - ZeroTrust (Score:2)
This move does undermine Google's BeyondCorp mantra to a degree.
https://cloud.google.com/beyondcorp/ [google.com]
This smells like uneducated journalist flamebait (Score:2)
There is no way that Google does not already have a fully firewalled internal network for employees with TFA and VPNs for access. That is pretty much standard for any company, especially since Google is a major cloud provider.
Also, having root access on a single box has nothing to do with enterprise network security. Those are two totally different issues. The standard at almost all companies, Google included, is to only give out a root credentials to employees with a need to have them.
This is probably idio