Or the time that Lockheed Martin who (despite a solid effort to include MFA on their VPN) was still attacked by a group who had found the random seeds used to generate tokens on their hardware MFA tokens.Īnd if you use your company’s WiFi network as a trusted network, that network can become an attack vector as well. When he gained access to one of their internal servers, he noticed leftover files from another pentester who had used the same vulnerability to steal a small number of internal credentials.Įxploits related to CVEs (common vulnerabilities and exposures) on VPN servers are all too common, such as the time that 900+ enterprise VPN servers had their passwords dumped, or when a commonly used VPN implementation allowed for direct access to I/O devices. Here’s a story where a bug bounty hunter attacked Facebook using this approach. Oftentimes, systems like VPN access points are a primary target. When a pentester or hacker attempts to attack your network, one very common approach is to search for vulnerabilities in any public-facing server of yours they can find. It doesn’t matter what device attempts to access, even our CEO’s laptop will need to authenticate securely before viewing the site’s contents. In contrast, BeyondCorp encourages consistent authentication throughout all parts of an application for all devices.
And with the rise of remote work, cell phones, and other mobile devices, your “secure” network of trusted devices is becoming wider all the time. Once access is gained into a system, all the data inside that network is accessible. VPNs create “eggshell” security, where all protections happen at the perimeter. Side note: You can check out some of our publicly facing tutorials at How is this better than a VPN? While the DNS is public, only our internal employees can gain access to our internal tutorials, and you won’t be allowed in unless you have an email address. Once I gain access to the site, I won’t need to log in to any internal systems for an hour. Note that this includes a hardware MFA token requirement that is easily enforceable across an entire GSuite organization (and many other identity providers).
When I attempt to load the site, it asks me to login with my GSuite credentials. But what does it look like in real life? Well, let’s see what happens when I go to Transcend’s internal codelabs site, where we have set up BeyondCorp authentication with our company’s GSuite credentials:
What would this look like as a user?īeyondCorp is filled with buzz words. This blog post aims to provide a practical implementation guide for using BeyondCorp security on your internal websites hosted in AWS.Īt Transcend, we use BeyondCorp security to ensure our IP and our users’ data stays safe. That’s a lot to ask!īut we also believe that getting started with BeyondCorp is much easier than many may think, and that the security payoffs can come immediately. It asks you to look at every single request flowing through your system and to validate it’s legitimacy based on multiple data sources: where is the request coming from, who is sending it, what is the security status of that source, etc. This is despite the fact that Google’s whitepaper explaining the idea was released in 2014. This idea has been widely praised by security researchers, though practical guides on getting started with it on the most popular cloud platforms are still limited. This gave birth to BeyondCorp, a theoretical model for protecting all of your applications without the use of a VPN. But once Google became wary of this approach in 2009 after the Operation Aurora hack attempt, they decided to shift towards a zero-trust security model, where every request is treated as though it is coming from a network that could be compromised. This isn’t a new idea, as companies have been creating VPNs (virtual private networks) to restrict access to their internal networks for decades. So you should protect them to protect that data. Every company has them, and they often contain some of your company’s most important data.
0 kommentar(er)
