I quite like this
Seems like a good approach to the devices everywhere/BYOD issues we all face.
Let's hope they open source it!!
Google sees little distinction between board rooms and bars, cubicles and coffee shops; all are untrusted under its perimeter-less security model detailed in a paper published this week. The "BeyondCorp model" under development for more than five years is a zero-trust network model where the user is king and log in location …
I quite like the idea too. We need different approaches to security to reduce the number of security related incidents that occur. There seems to be a lot of effort going into removing bugs from software (including OS's) that facilitate security attacks which is a god thing. Where I don't see much in the way of developments is introducing new security features. How many OS's support data classification for example?
I can imagine this working with Chrome OS. The boot loader only loads a signed kernel. The kernel mounts the root partition and the first time each time each block is fetched, its signature is checked before passing it on to the file system layer. It is an effective way to test for a trusted image in the root partition without a big delay on boot. The source code has been available for years. The downside is the effort required to delete the vendor's keys and install your own so only your signed kernels and root file systems can boot may require hunting down an exploit in the supplies OS.
(Do not bother if the device has AMT - unless Intel suddenly document it sufficiently for you to audit it properly.)
I'm struggling to see the difference between this and a well designed Active Directory set up where user groups are used to configure access rights within a network.
They're talking about how this solves the problem of hackers waltzing around inside an open internal network, but that's exactly the problem that AD Groups and OUs are designed to solve. Aren't they? If you have a Windows network and you don't use Groups and OUs to segregate privileges within your network, what'd be the point in having an AD anyway?
From the article:
"Unlike the conventional perimeter security model, BeyondCorp doesn’t gate access to services and tools based on a user’s physical location or the originating network; instead, access policies are based on information about a device, its state, and its associated user."
What, just like a Windows AD Network?
And it's not even as if this is a problem that needs solving for Linux/Unix either - there's things like PowerBroker (or whatever it's called today) that add AD management of *nix boxes, which presumably these days can be driven from a Samba 4 AD DC instead of a Windows Server.
So is this Google simple reinventing the wheel / AD?
> I'm struggling to see the difference between this and a well designed Active Directory
This includes machine state information beyond joining state, kerberos state and time difference. So, it combines AD, client capabilites (like a Netscaler VPN gateway does - can check for basics like anti-virus status, patch status et. al.)
It also covers non-Windows machines (whether or not they are bound to AD).
I guess it's an extension of the old single-sign-on mantra but with client capabilities thrown into the mix.
Interesting, but given the Google habit of hoovering up your info to feed its insatiable appetite for other peoples data, I'd be a bit sceptical - unless it's open-sourced and gone over with a fine-toothed comb. Especially sceptical if Google are selling it as a service that they provide.
(disclaimer: dev, not sysadmin, here)
I like the idea that you're paranoid everywhere and all the time. But I did not see BYOD mentioned in the article. In fact, I wonder how their BYOD posture is set up, given that their trust/distrust model is based on device + user. Would be nice if that had been explored in the article.
Google may not be to everyone's liking, but they are quite clever and often have interesting ideas. Hadoop, for example, was inspired by their MapReduce publication.
I can see how you might retrospectively apply this once you've been running with "traditional" perimiter security for long enough to have been able to gather the data about devices, services and patterns of behaviour.
Not sure how you do this with a new business - or indeed just a new outpost of an existing business, so you still incur all the initial pain of manual configuration. Interesting potehtial, though.
> Just because "Google says", doesn't make something interesting, relevant, new, or newsworthy.
Would you have found the BeyondCorp approach interesting only if it came from somewhere else?
For too long people have taken false comfort from firewalls. "We have a firewall, we are secure". "You are behind the firewall, your device is secure". "You are behind the firewall, you are trustworthy". All three are huge fallacies, but there is much inertia about changing the broken corporate security mindset.
Thumbs up to Google for going ahead and doing it anyway - proving it can be done successfully, and giving a template to wave under your PHB's nose if they say it can't.
Ever had a PHB actually declare something like that to the local press ? I have.
We got ripped to shreds by a worm that someone downloaded with some random screensaver, and I was on holiday when I saw that news article.
They could probably hear me face-palming from 200 miles away, let alone see the flash and the mushroom cloud from the resulting F-bomb.
What a pointless comment - nothing to do with the article at all.
I disagree. We're seeing far too much of "Google says this", followed by basic knowledge that anyone in the industry for more than six months should have.
Just because "Google says", doesn't make something interesting, relevant, new, or newsworthy.
Unfortunately, the media in general has a tendency to consider anyone who has made a lot of money as all-knowing. It's the same fun idea that assumes that people who are successful in repeatedly going bankrupt to avoid debts and then reconstruct their fortune from where it was ferreted away are in any way capable of running a country. Made a lot of money making furniture? Sure, you are qualified to talk about space travel! (no, don't go looking for that, it's only an example).
I agree with an earlier comment I have seen: I would not trust anything from or by Google. Even if it appears to make sense, because in the case of Google you always have to treat the advice as if it comes from a banker or a politician: examination to find out in which way you are being screwed is mandatory.
I'll stick to Best Practice, thanks. I've kept whole governments safe that way.
You have to remember that Google are primarily a *data* collection and sales company and after the various revelations, perhaps not too fussy how they aquire that data either. Nor where it ends up / who it is sold to. If you value your privacy, know what your are dealing with.
Sounds like a good idea though, but I wouldn't trust them an inch either...
Stealing the device does not necessarily depriving the owner of the property e.g taking their laptop physically, it can refer to stealing control of the device (not necessarily real time control) and it can can refer to collecting data e.g. key logging etc. I do not believe that Google have managed to prevent that from happening, do you?
> it can refer to stealing control of the device (not necessarily real time control) and it can can refer to collecting data e.g. key logging etc. I do not believe that Google have managed to prevent that from happening, do you?
As I understand it: they audit each device, ensure all the patches are up to date, and run various vulnerability scans across them, before authorizing it.
Essentially they are automating "best practice" for managing devices.
Nobody can totally *prevent* key logging - but if you do all those things you minimise your risk. And their gateway won't give you access to their systems unless your device has had all those things done to it.
I read through their white paper and it raised some interesting points. Most importantly, in my view, is their emphasis on incorporating mobile devices into their security model. On the other hand, two of the three references in their paper were Wikipedia pages. Too, their model depends on the use of a certificate authority, which might point to a possible way for someone to compromise their system.
It's probably the future but this sounds difficult to support.
Perimiter security model
"Hey support, how do I access this app?"
"Log in to the network"
"Hey support, how do I access this app?"
"Well your trust level score needs to be above 40 for that app. The score is calculated based on 15 sources, including Active Directory; Puppet; and Simian; various configuration and corporate asset management systems; vulnerability scanners; certificate authorities, and network infrastructure elements such as ARP tables"
This sort of thing has been done before.
See for example Jericho Forum, I remember being involved in discussions about that somewhere around the 2002 mark. There was some serious buy-in for Jericho from CISOs at the sort of places where you'd expect de-perimeterisation to be considered the devil.
Don't know what happened to Jericho, my line of work changed a bit in the intervening years...
Thank you AC for this - I also remember the Jericho Forum, and also the Trusted Computing Group.
This looks like a re-badging exercise to give the impression that they are still innovative.
As for the noise about accelerating this due to the Snowden revelations, I think we can be fairly assured that US companies will never stop co-operating with the agencies - they have too much at stake to irritate these people: the US government does wield significant commercial influence. And commercial influence is a much more effective stick than anything else.
We're having a hard time describing a "trusted system/asset" to our IT security department. We have legacy programs running back decades. Some of our test stations require Windows 2000 or Windows XP (due in part to no longer existent software vendors), and therefore can never be trusted. This solution sounds nice for Google, a purely "cloud based software house", but we're finding the realities of our system prevent closed trust models like this. Sometimes, you just have to rely on the network to do the security for you, and isolate that network from the more sensitive data and services. We're having to revert to "Sneaker Net" because we can't work out a good system.
Why does Google, who insist upon so much attention to security internally and in OTHER people's software (Project Zero), allow their Android OS to be the single most dangerous mobile OS available? Why can't they REALLY vet their Google Play Store? Why can't they insist upon ASAP updating across the entire Android spectrum of devices, ending the nightmare that is fragmandroid?
Google: Cognitive Dissonance
Seems like they just shrunk the corporate perimeter to be around the resources, shoving all the users outside that perimeter. Then, all those tiny perimeters (each individual) has to be somehow secure in an untrusted network ocean full of (wire)sharks. Pwning is still easy although a tad harder-- we work on HSMs and trying to seal all the security pinholes in something with real security just shows how little Beyond is buying. The biggest advantage of Beyond is probably abandoning the complacency CISOs get from a corporate moat-and-bunker mentality.
(a plus from HR's perspective is that all those outside the resource perimeter can be easily jettisoned as worthless cogs when the time comes, with cheaper cogs easily popped into place)
The new approach seems interesting, but only time and more hands-on experience will tell if it's better than the status quo.
My doubt concerns the devices as part as user rights giver. Devices can be easily hacked, and when you have hundreds if not thousands of different kinds of devices, how can you be sure you are on top of security ? This is also relevant if you need to give external partners access ton in-house IT resources.
> Staff devices including laptops and phones are logged into a device inventory service which contains trust information and snapshots of the devices at a given time. <
So the single point of failure doesn't simply supply information about a user and what they are authorised to do but about their device and its state too!
> [which] reduces maintenance cost and improves device usability. <
Yes, much less overhead than a username/uid/password-hash/policy-set combo.
> "Unlike the conventional perimeter security model, BeyondCorp doesn’t gate access to services and tools based on a user’s physical location or the originating network; <
If you're authorising users based upon location/network you need to rethink your security - I don't care where you are: are you who you claim to be?
> instead, access policies are based on information about a device, its state, and its associated user. <
You mean lending my phone to that bloke on the street corner wasn't a good idea after all?
> "BeyondCorp considers both internal networks and external networks to be completely untrusted, <
And here I've been all this time, granting users access to everything because no-one could be inside my network who shouldn't be.
> and gates access to applications by dynamically asserting and enforcing levels, or tiers, of access." <
So, I've been barking up completely the wrong tree with ACLs and R(S)BAC all this time?
> The zero trust architecture spells trouble for traditional attacks that rely on penetrating a tough perimeter to waltz freely within an open internal network. <
I really must get around to subnetting and segmenting my network one of these days, really I must.
Biting the hand that feeds IT © 1998–2019