Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Friday February 17 2017, @03:31AM   Printer-friendly
from the trust-no-one dept.

Submitted via IRC for chromas

Google may have sent the tired castle analogy of network security's soft center protected by a tough exterior out to pasture for good.

On Tuesday at RSA Conference, Google shared the seven-year journey of its internal BeyondCorp rollout where it affirms trust based on what it knows about its users and devices connecting to its networks. And all of this is done at the expense—or lack thereof—of firewalls and traditional network security gear.

Director of security Heather Adkins said the company's security engineers had their Eureka moment seven years ago, envisioning a world without walls and daring to challenge the assumption that existing walls were working as advertised.

"We acknowledged that we had to identify [users] because of their device, and had to move all authentication to the device," Adkins said.

Google, probably quicker than most enterprises, understood how mobility was going to change productivity and employee satisfaction. It also knew that connecting to corporate resources living behind the firewall via a VPN wasn't a longterm solution, especially for those connecting on low-speed mobile networks where reliability quickly became an issue.

The solution was to flip the problem on its head and treat every network as untrusted, and grant access to services based on what was known about users and their device. All access to services, Adkins said, must then be authenticated, authorized and on encrypted connections.

"This was the mission six years ago, to work successfully from untrusted networks without the use of a VPN," Adkins said.

Source: https://threatpost.com/no-firewalls-no-problem-for-google/123748/


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Insightful) by edIII on Friday February 17 2017, @04:29AM

    by edIII (791) on Friday February 17 2017, @04:29AM (#468082)

    I guess that works for services.... but how does that work to secure a network again? Actually secure it?

    There is technically a firewall still in operation, it's just called an API now. You are STILL operating a service on some sort of port. Even bootstrapping a connection and moving it to another port requires the initial port. So the device authenticates, and from that point on other services may start to listen to it? Is every port open by default, or just the ones that offer authentication services?

    Ummm, but the whole point of the firewall in many, many, many cases is to PREVENT that service from doing anything in the first place until a curated white list tells you that it's okay. Take Asterisk for instance. You *could* rely on SIP to authenticate all of the connections but that makes you reliant on two very important items:

    1) SIP is a perfect protocol not subject to any attacks upon its attack surface
    2) Those resources used for authentication are there and available

    I happen to know on #1 that SIP is not perfect, and really can't be trusted. Since some platforms have moved to database operations (Asterisk) sip attack programs have added SQL injection attacks to their known attack surfaces. On #2, it makes a HUGE difference to protect your transports from public access. I saw upwards of ONE HALF of all Asterisk resources used to serve bogus SIP registration/invite requests for sipvicious and other script kiddie tools. It's so relentless that for registration you need a white-list if you want to even read your console screen anymore to see the wall of diagnostics that relates to legitimate activity.

    This sounds like so many different attack surfaces are open by default, and that a firewall still exists on the server itself. That's sounds like a bad idea when you can isolate the firewall to a group of servers on the network edge and not be running thousands of firewalls requiring remote management.

    Maybe the idea sounds great, but only if you can move some serious authentication to the devices. Google can do that with its custom security silicon, but I'm SURE that it also means the servers are all custom too. Otherwise that means Google solved all the typical attack surfaces that a firewall is designed to prevent access to?

    It's dubious at best that Google really removed all of the firewalls, and didn't just MOVE the firewalls to the devices themselves.

    In other words, Google is trying to convince us that surfing the Internet without condoms on is a real thing now.

    --
    Technically, lunchtime is at any moment. It's just a wave function.
    Starting Score:    1  point
    Moderation   +2  
       Insightful=1, Interesting=1, Total=2
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 2) by coolgopher on Friday February 17 2017, @06:27AM

    by coolgopher (1157) on Friday February 17 2017, @06:27AM (#468109)

    Indeed.

    And remind me again, what was wrong with Kerberos?

    • (Score: 2) by canopic jug on Friday February 17 2017, @06:01PM

      by canopic jug (3949) Subscriber Badge on Friday February 17 2017, @06:01PM (#468278) Journal

      Kerberos V was quite good until M$ deliberately killed it. I'd like to see a Kerberos VI developed without M$ interference with an effort made to simplify and clarify the code base. LibreSSL provides a good model for how a project can work. But Kerberos VI is unlikely to happen because the universities have no spine any more to go against M$ and have become more bureaucratic than academic.

      --
      Money is not free speech. Elections should not be auctions.
  • (Score: 2) by darkfeline on Friday February 17 2017, @06:33PM

    by darkfeline (1030) on Friday February 17 2017, @06:33PM (#468299) Homepage

    The way I interpreted the summary: Instead of the industry standard practice of having all internal services basically unauthenticated and unsecured, and securing external access via firewall and VPN, all internal services authenticate every single connection. Thus you don't really need the firewall+VPN anymore. Anyone who would have been able to access VPN and thus have full access to all internal services would be able to authenticate to each service individually, and the inverse, converse, and contrapositive holds as well.

    But once you have authentication on every connection, the firewall+VPN combo is kind of redundant, it's not really adding any extra security since anyone who could have authed individually could auth via VPN.

    --
    Join the SDF Public Access UNIX System today!