7 ms·

> “Enterprise applications should be able to be used over the public internet.” Isn’t exposing your internal domains and systems outside VPN-gated access a ris

> “Enterprise applications should be able to be used over the public internet.” Isn’t exposing your internal domains and systems outside VPN-gated access a risk? My understanding is this means internaltool.faang.com should now be publicly accessible.

3np 5y ago
There are different ways to look at it. From a defense-in-depth perspective, you are right. That is, however, one of the main points of a zero-trust environment (or you could say Zero Trust), which is a kind-of-new trend that much has been written about. Think about it this way: In the context of ransomware attacks, a lot of times it's game over once an internal agent is compromised. The premise of zero trust is that once an attacker is "inside the wall", they gain basically nothing. Compromising one service or host would mean having no venue for escalation from there. I wouldn't say it's objectively better (maybe by the time I retire I can make a call on that), but it's a valid strategy. Certainly better than relying on perimeter-based security like VPN alone, as opposed to it being just one layer of DiD, though.
enriquto 5y ago
As I understand it, this sentence says that the application should be safe even if it was exposed to the public internet, not that it needs to be exposed. It is a good practice to securize everything even if visible only internally. The "perimeter defense" given by a VPN can be a plus, but never the only line of defense.
- jaywalk 5y ago
  No, the memo pretty clearly says that VPNs need to go away.
  - deleted 5y ago
    [deleted]
  - MattPalmer1086 5y ago
    It says that VPNs and other network tunnels should not be relied on. Where does it say they should go away?
    - nybble41 5y ago
      "Further, Federal applications cannot rely on network perimeter protections to guard against unauthorized access. Users should log into applications, rather than networks, and enterprise applications should eventually be able to be used over the public internet. In the near-term, every application should be treated as internet-accessible from a security perspective. As this approach is implemented, agencies will be expected to stop requiring application access be routed through specific networks, consistent with CISA’s zero trust maturity model." "Actions … 4. Agencies must identify at least one internal-facing FISMA Moderate application and make it fully operational and accessible over the public internet."
      - shkkmo 5y ago
        Which is saying that agencies have to stop relying on / requiring VPNs for authorization and access control, not that any user has to stop using VPNs.
        nybble41 5y ago
        It's true that they didn't mandate detecting and blocking accesses from VPNs, if the user chooses to connect through one. However, they pretty clearly are saying that the application should be exposed to the public Internet, which is the opposite of what enriquto claimed[0] earlier in this thread: > As I understand it, this sentence says that the application should be safe even if it was exposed to the public internet, not that it needs to be exposed. [0] https://news.ycombinator.com/item?id=30103558 https://news.ycombinator.com/item?id=30103558
      - MattPalmer1086 5y ago
        Yes, good point. I wonder if that applies to all infrastructure, or just enterprise applications.
- deleted 5y ago
  [deleted]
- joshgachnang 5y ago
  The memo does say each agency needs to pick one system that is not internet accessible and make it accessible in the next year. The way I read this memo is pushing that VPNs don't add much in the way of security (if you follow the rest of the memo) and should be removed.
  - tptacek 5y ago
    The other way to read that part of the memo is that the exercise of exposing an application on the public Internet is a forcing function that will require agencies to build application security skills necessary whether or not they use VPNs. Note that the memo demands agencies find a single FISMA-Moderate service to expose.
formerly_proven 5y ago
It's a different framing to get rid of figleafs. Everything has to be built so that it actually has a chance of being secure - if your state of mind is "this is exposed to the public internet", BS excuses like "this is only exposed to the TotallySecure intranet" don't work any more, because they don't work in the first place. Perimeter security only works in exceedingly narrow circumstances which don't apply - and haven't applied for a long time[1] - to 99.999 % of corporate networks. [1] Perimeter-oriented security thinking is probably the #1 enabler for ransomware and lateral movement of attackers in general.
- 3np 5y ago
  For anyone confused about the term "figleaf", I assume it's a reference to fig leafs being used by Renaissance artists to mask genitalia. So "things concealing the naked truth" approximately.
  - jsmith99 5y ago
    It's older than that: it's a biblical reference to Adam and Eve covering themselves.
    - 3np 5y ago
      My memory serves me wrong; thought that it being a fig leaf in particular was newer than the Bible but it's not (Genesis 1:3:7)
- lethargic_meat 5y ago
  This sounds like the meme of holding a riffle like a pistol, so your fear for getting smacked with the butt makes you impervious to recoil.
bspammer 5y ago
I believe Google uses https://cloud.google.com/beyondcorp https://cloud.google.com/beyondcorp
nonameiguess 5y ago
The point isn't to actually expose your internal services. It's to not assume that attackers can't breach your network perimeter. Internal traffic should be treated with the same level of trust as external traffic, that is, none at all.
Sesse__ 5y ago
internaltool.faang.com _is_ publicly accessible, as in, you can get to the login page.
tptacek 5y ago
It is a risk. The discourse on VPNs is messy. It's true that you shouldn't rely solely on VPNs for access control to applications. It's also true that putting important services behind a VPN significantly reduces your attack surface, and also puts you in a position to get your arms around monitoring access. The right way to set this stuff up is to have a strong modern VPN (preferably using WireGuard, because the implementations of every other VPN protocol are pretty unsafe) with SSO integration, and to have the applications exposed by that VPN also integrate with your SSO. Your users are generally on the VPN all day, and they're logging in to individual applications or SSH servers via Okta or Google. "RIP VPNs" is not a great take.
- SecurityLagoon 5y ago
  Thanks for saying this. This was exactly my take. Saying goodbye to VPNs just completely ignores the risk of RCE vulnerabilities on your services. You can have a VPN that still brings you into a zero trust network.
  - tptacek 5y ago
    It does essentially define away the authentication bypass problem, which is a class of vulnerability we still regularly find in modern web applications. To say nothing of the fact that no human has ever implemented a SAML RP without a game-over vulnerability. Seems like a self-evidently bad plan.
- emptysongglass 5y ago
  I don't like VPNs. I think there's better ways of protecting our infrastructure without them. AWS offers a lot of technologies for doing just that. A VPN is another failure layer that when it goes down all of your remote workers are hosed. The productivity losses are immense. I've seen it first-hand. The same for bastion hosts. Some tiny misconfiguration that sneaks in and everybody is fubared. Bastion hosts and VPNs: we have better ways of protecting our valuables that's also a huge win for worker mobility and security.
  - 5y ago
zajio1am 5y ago
Well, we can just move from traditional VPNs to IPSec in transport mode.
mjg59 5y ago
$ host buganizer.corp.google.com buganizer.corp.google.com is an alias for uberproxy.l.google.com. uberproxy.l.google.com has address 142.250.141.129 uberproxy.l.google.com has IPv6 address 2607:f8b0:4023:c0b::81 Google's corp services are publicly accessible in that sense - but you're not getting through the proxy without valid credentials and (in most cases) device identity verification.
- joshuamorton 5y ago
  Not to mention login.corp.google.com (which has been on the frontpage of HN before!).
rodgerd 5y ago
The thing is that over-focus on perimeter security is still a huge problem, and one reason that e.g. ransomware owns orgs with depressing regularity. There's nothing wrong with perimeter controls in and of themselves. But they become a substitute for actually security what's on the internal network, so once you've bypassed the perimeter, it's all too easy to roam at will. The people over-relying on perimeter security are the folks buying a big sixties car and assuming that seatbelts and traction control are no substitute for chrome bumpers.

3np 5y ago

There are different ways to look at it. From a defense-in-depth perspective, you are right. That is, however, one of the main points of a zero-trust environment (or you could say Zero Trust), which is a kind-of-new trend that much has been written about. Think about it this way: In the context of ransomware attacks, a lot of times it's game over once an internal agent is compromised. The premise of zero trust is that once an attacker is "inside the wall", they gain basically nothing. Compromising one service or host would mean having no venue for escalation from there. I wouldn't say it's objectively better (maybe by the time I retire I can make a call on that), but it's a valid strategy. Certainly better than relying on perimeter-based security like VPN alone, as opposed to it being just one layer of DiD, though.

enriquto 5y ago

As I understand it, this sentence says that the application should be safe even if it was exposed to the public internet, not that it needs to be exposed. It is a good practice to securize everything even if visible only internally. The "perimeter defense" given by a VPN can be a plus, but never the only line of defense.

jaywalk 5y ago
No, the memo pretty clearly says that VPNs need to go away.
- deleted 5y ago
  [deleted]
- MattPalmer1086 5y ago
  It says that VPNs and other network tunnels should not be relied on. Where does it say they should go away?
  - nybble41 5y ago
    "Further, Federal applications cannot rely on network perimeter protections to guard against unauthorized access. Users should log into applications, rather than networks, and enterprise applications should eventually be able to be used over the public internet. In the near-term, every application should be treated as internet-accessible from a security perspective. As this approach is implemented, agencies will be expected to stop requiring application access be routed through specific networks, consistent with CISA’s zero trust maturity model." "Actions … 4. Agencies must identify at least one internal-facing FISMA Moderate application and make it fully operational and accessible over the public internet."
    - shkkmo 5y ago
      Which is saying that agencies have to stop relying on / requiring VPNs for authorization and access control, not that any user has to stop using VPNs.
      - nybble41 5y ago
        It's true that they didn't mandate detecting and blocking accesses from VPNs, if the user chooses to connect through one. However, they pretty clearly are saying that the application should be exposed to the public Internet, which is the opposite of what enriquto claimed[0] earlier in this thread: > As I understand it, this sentence says that the application should be safe even if it was exposed to the public internet, not that it needs to be exposed. [0] https://news.ycombinator.com/item?id=30103558 https://news.ycombinator.com/item?id=30103558
    - MattPalmer1086 5y ago
      Yes, good point. I wonder if that applies to all infrastructure, or just enterprise applications.
deleted 5y ago
[deleted]
joshgachnang 5y ago
The memo does say each agency needs to pick one system that is not internet accessible and make it accessible in the next year. The way I read this memo is pushing that VPNs don't add much in the way of security (if you follow the rest of the memo) and should be removed.
- tptacek 5y ago
  The other way to read that part of the memo is that the exercise of exposing an application on the public Internet is a forcing function that will require agencies to build application security skills necessary whether or not they use VPNs. Note that the memo demands agencies find a single FISMA-Moderate service to expose.

formerly_proven 5y ago

It's a different framing to get rid of figleafs. Everything has to be built so that it actually has a chance of being secure - if your state of mind is "this is exposed to the public internet", BS excuses like "this is only exposed to the TotallySecure intranet" don't work any more, because they don't work in the first place. Perimeter security only works in exceedingly narrow circumstances which don't apply - and haven't applied for a long time[1] - to 99.999 % of corporate networks. [1] Perimeter-oriented security thinking is probably the #1 enabler for ransomware and lateral movement of attackers in general.

3np 5y ago
For anyone confused about the term "figleaf", I assume it's a reference to fig leafs being used by Renaissance artists to mask genitalia. So "things concealing the naked truth" approximately.
- jsmith99 5y ago
  It's older than that: it's a biblical reference to Adam and Eve covering themselves.
  - 3np 5y ago
    My memory serves me wrong; thought that it being a fig leaf in particular was newer than the Bible but it's not (Genesis 1:3:7)
lethargic_meat 5y ago
This sounds like the meme of holding a riffle like a pistol, so your fear for getting smacked with the butt makes you impervious to recoil.

bspammer 5y ago

I believe Google uses https://cloud.google.com/beyondcorp https://cloud.google.com/beyondcorp

nonameiguess 5y ago

The point isn't to actually expose your internal services. It's to not assume that attackers can't breach your network perimeter. Internal traffic should be treated with the same level of trust as external traffic, that is, none at all.

Sesse__ 5y ago

internaltool.faang.com _is_ publicly accessible, as in, you can get to the login page.

tptacek 5y ago

It is a risk. The discourse on VPNs is messy. It's true that you shouldn't rely solely on VPNs for access control to applications. It's also true that putting important services behind a VPN significantly reduces your attack surface, and also puts you in a position to get your arms around monitoring access. The right way to set this stuff up is to have a strong modern VPN (preferably using WireGuard, because the implementations of every other VPN protocol are pretty unsafe) with SSO integration, and to have the applications exposed by that VPN also integrate with your SSO. Your users are generally on the VPN all day, and they're logging in to individual applications or SSH servers via Okta or Google. "RIP VPNs" is not a great take.

SecurityLagoon 5y ago
Thanks for saying this. This was exactly my take. Saying goodbye to VPNs just completely ignores the risk of RCE vulnerabilities on your services. You can have a VPN that still brings you into a zero trust network.
- tptacek 5y ago
  It does essentially define away the authentication bypass problem, which is a class of vulnerability we still regularly find in modern web applications. To say nothing of the fact that no human has ever implemented a SAML RP without a game-over vulnerability. Seems like a self-evidently bad plan.
emptysongglass 5y ago
I don't like VPNs. I think there's better ways of protecting our infrastructure without them. AWS offers a lot of technologies for doing just that. A VPN is another failure layer that when it goes down all of your remote workers are hosed. The productivity losses are immense. I've seen it first-hand. The same for bastion hosts. Some tiny misconfiguration that sneaks in and everybody is fubared. Bastion hosts and VPNs: we have better ways of protecting our valuables that's also a huge win for worker mobility and security.
- 5y ago

zajio1am 5y ago

Well, we can just move from traditional VPNs to IPSec in transport mode.

mjg59 5y ago

$ host buganizer.corp.google.com buganizer.corp.google.com is an alias for uberproxy.l.google.com. uberproxy.l.google.com has address 142.250.141.129 uberproxy.l.google.com has IPv6 address 2607:f8b0:4023:c0b::81 Google's corp services are publicly accessible in that sense - but you're not getting through the proxy without valid credentials and (in most cases) device identity verification.

joshuamorton 5y ago
Not to mention login.corp.google.com (which has been on the frontpage of HN before!).

rodgerd 5y ago

The thing is that over-focus on perimeter security is still a huge problem, and one reason that e.g. ransomware owns orgs with depressing regularity. There's nothing wrong with perimeter controls in and of themselves. But they become a substitute for actually security what's on the internal network, so once you've bypassed the perimeter, it's all too easy to roam at will. The people over-relying on perimeter security are the folks buying a big sixties car and assuming that seatbelts and traction control are no substitute for chrome bumpers.