<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 29 August 2016 at 16:41, Marc Boorshtein <span dir="ltr"><<a href="mailto:marc.boorshtein@tremolosecurity.com" target="_blank">marc.boorshtein@tremolosecurity.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">><br>
> VPNs are certainly not the solution in all cases as more and more<br>
> applications are exposed directly on the Internet everyday.<br>
<br>
</span>Very true (as are all your other statements) but my point about VPNs<br>
wasn't that more people are using VPNs as a way to protect<br>
applications (probably the opposite). Its that VPNs can be easily<br>
used to bypass many of the features of adaptive authentication. Most<br>
adaptive deployments I've seen rely on geo location mappings of IP<br>
ranges to determine where users are logging in from. Use an OpenVPN<br>
into a Amazon/Google/Azure/Pick-Your-<wbr>Favorite-Proider network and out<br>
to the internet and that feature becomes useless.<br></blockquote><div><br></div><div>Yep, that's an issue. There's also bot farms as well. Not many people will issue an attack from their home address.</div><div><br></div><div>Still has some level of protection. For example VPNs are costly, tend to be rate limited.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Looking at the list Thomas provided, 6 of them can easily be spoofed<br>
or circumvented:<br>
<br>
VPNs from a private server in the cloud would circumvent these<br>
<span class="">- IP Address Range - ip IP not in IP range raise risk<br>
- IP Address History - if IP not in IP address history raise risk<br></span></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span><span class="">- GeoLocation - if IP geolocation based on<br>
<a href="http://www.maxmind.com/app/country" rel="noreferrer" target="_blank">http://www.maxmind.com/app/<wbr>country</a> is not from a certain area raise<br>
risk<br></span></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
</span>And these can be bypassed by a browser plugin:<br>
<span class="">- Known cookie - if a certain cookie + value not present raise risk<br>
- Device cookie - if not a known or trusted device raise risk<br></span></blockquote><div><br></div><div>Not if the value is associated with the user and signed with the realm keys.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span><span class="">- RequestHeader - if certain request header is not present raise risk<br>
<br>
</span>(additionally, many enterprises deploy GPOs that clear persistent<br>
cookies, which is how a device cookie is implemented) </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
While these are certainly only examples of rules that can be used,<br>
most of the really interesting rules requires a considerable amount of<br>
data and analysis to be useful. That data needs to be kept up-to-date<br>
as does the analysis.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'd amend your statement on layered security to be "effective" layered<br>
security. If someone is trusting a security mechanism that either<br>
isn't kept updated as needed or is not providing the expected security<br>
becomes a liability. I've seen plenty of examples of folks relying on<br>
a security mechanism that didn't supply nearly the security they<br>
thought it did and it didn't work out too well.<br></blockquote><div><br></div><div>Definitively true - there's some serious false sense of security in implementing random security defenses that have no real level of protection.</div></div><br></div></div>