"Winning" and "Losing" are not a great framework for this sort of analysis. In that binary framework, there's no difference between "1 bit of sensitive data was leaked" and "the medical and financial records of every person ever, nuclear launch codes, and the backdoor that causes every nuclear reactor to go critical simultaneously were leaked" - both are just "losing".
This is why various compartmentalization techniques exist throughout the stack - principle of least privilege, network segmentation, acls, and so on. If something is compromised, limit the "blast radius" of what can be done with that compromise.
The other part is containment. By analogy alarm systems and guards. If the alarm system goes off and says an intruder is in the building, well by the "winning and losing" framework, the defender has already lost. (Of course by the binary framework, you don't even need an internal alarm system - once the breach occured you've lost so why bother?). Or you could try to contain the problem and send guards to stop the intruder before they do too much damage.
This is where the cloudflared usage described in the article is problematic. It's a tool that is less likely to trip alarm systems, and further can provide a wide range of access while doing so[1]. If it doesn't trip alarms, a small breach leaking a little data can turn into a big breach leaking lots of data. It absolutely should be considered when designing networks, security methods, etc.
I don't know what the solution here is, that probably depends on the individual/org doing the threat assessment, and probably varies by environment within that domain. Should the tool be blanket banned? Probably not it's also a really useful tool for a lot of people in a a lot of situations. Maybe cloudflare can split the tool in to individual binaries for functionality and have the tool called cloudflared just be a wrapper. Maybe they can change it some other way.
[1] this tool is used for a lot of stuff and may already be on the systems in question, so it's not even installing a program -- just execing it. Since it is used for a lot of different things, it may just be on a blanket "allow this app" list. And so on.
This is why various compartmentalization techniques exist throughout the stack - principle of least privilege, network segmentation, acls, and so on. If something is compromised, limit the "blast radius" of what can be done with that compromise.
The other part is containment. By analogy alarm systems and guards. If the alarm system goes off and says an intruder is in the building, well by the "winning and losing" framework, the defender has already lost. (Of course by the binary framework, you don't even need an internal alarm system - once the breach occured you've lost so why bother?). Or you could try to contain the problem and send guards to stop the intruder before they do too much damage.
This is where the cloudflared usage described in the article is problematic. It's a tool that is less likely to trip alarm systems, and further can provide a wide range of access while doing so[1]. If it doesn't trip alarms, a small breach leaking a little data can turn into a big breach leaking lots of data. It absolutely should be considered when designing networks, security methods, etc.
I don't know what the solution here is, that probably depends on the individual/org doing the threat assessment, and probably varies by environment within that domain. Should the tool be blanket banned? Probably not it's also a really useful tool for a lot of people in a a lot of situations. Maybe cloudflare can split the tool in to individual binaries for functionality and have the tool called cloudflared just be a wrapper. Maybe they can change it some other way.
[1] this tool is used for a lot of stuff and may already be on the systems in question, so it's not even installing a program -- just execing it. Since it is used for a lot of different things, it may just be on a blanket "allow this app" list. And so on.