On 29 August 2016 at 16:41, Marc Boorshtein <
marc.boorshtein(a)tremolosecurity.com> wrote:
>
> VPNs are certainly not the solution in all cases as more and more
> applications are exposed directly on the Internet everyday.
Very true (as are all your other statements) but my point about VPNs
wasn't that more people are using VPNs as a way to protect
applications (probably the opposite). Its that VPNs can be easily
used to bypass many of the features of adaptive authentication. Most
adaptive deployments I've seen rely on geo location mappings of IP
ranges to determine where users are logging in from. Use an OpenVPN
into a Amazon/Google/Azure/Pick-Your-Favorite-Proider network and out
to the internet and that feature becomes useless.
Yep, that's an issue. There's also bot farms as well. Not many people will
issue an attack from their home address.
Still has some level of protection. For example VPNs are costly, tend to be
rate limited.
Looking at the list Thomas provided, 6 of them can easily be spoofed
or circumvented:
VPNs from a private server in the cloud would circumvent these
- IP Address Range - ip IP not in IP range raise risk
- IP Address History - if IP not in IP address history raise risk
History wouldn't be that easy to spoof. However, loads of people have
dynamic IP addresses so it would end up raising the risk for legitimate
users.
- GeoLocation - if IP geolocation based on
http://www.maxmind.com/app/country is not from a certain area raise
risk
The IP address of a large portion of attacks still come from certain
regions, so it does provide some level of protection even though it can be
circumvented.
And these can be bypassed by a browser plugin:
- Known cookie - if a certain cookie + value not present raise risk
- Device cookie - if not a known or trusted device raise risk
Not if the value is associated with the user and signed with the realm keys.
- RequestHeader - if certain request header is not present raise
risk
(additionally, many enterprises deploy GPOs that clear persistent
cookies, which is how a device cookie is implemented)
While these are certainly only examples of rules that can be used,
most of the really interesting rules requires a considerable amount of
data and analysis to be useful. That data needs to be kept up-to-date
as does the analysis.
It does depend on what level of protection you are looking for. If it's for
a web application and you're trying to block out script kiddies and other
people looking for easy targets the rules doesn't have to be that complex.
I'd amend your statement on layered security to be "effective" layered
security. If someone is trusting a security mechanism that either
isn't kept updated as needed or is not providing the expected security
becomes a liability. I've seen plenty of examples of folks relying on
a security mechanism that didn't supply nearly the security they
thought it did and it didn't work out too well.
Definitively true - there's some serious false sense of security in
implementing random security defenses that have no real level of protection.