Security’s Last Mile: The User

Lori MacVittie 缩略图
Lori MacVittie
Published June 28, 2016

When we talk about “the last mile” in networking, we’re usually talking about that leg of the Internet where data moves between the provider’s network to the user’s network. That used to be a single machine, for most consumers. Today’s it’s their combination router/access point which is, ultimately, another network.

That’s because generally speaking that’s the piece of the pipeline we (as in purveyors of solutions designed to optimize performance) had no real control over. At that point, whatever we could do in terms of speeding up app delivery, we’d already done. Because we couldn’t really muck with the devices that formed that last mile between the provider and the user.

That’s still mostly true today, though certainly there are still ways for us to muck with the higher order layers of the network (layers 4 – 7) to improve performance even without that control. But when it comes to security, especially for those whose primary user based is consumer, the last mile struggle is very real.

That’s because the last mile for security is the user; or to be more precise, the user’s device, PC, or that “thing” reporting back in to its mother app in the sky (a.k.a. the cloud). Because many of the interactions that take place between consumers and providers involve money, there is a very real need for a high level of sensitivity toward the security of said transactions.

Which, like the performance challenges of the past, are really super hard to address when you don’t own “the last mile.”

That may explain why 30% of respondents in this years State of Application Delivery survey said an “Anti-fraud endpoint protection” was important in order for their organization to adopt cloud computing.

security posture soad16

Consider that, today, those same respondents are securing applications across the entire spectrum of communication: from client to the requests they make to the responses returned. While organizations appear to vary based on the application, there are a significant number of orgs who always (or at least that’s what they told us) enable protection at all three potential threat vectors.

Given the increasing volume of malware and the continued success of phishing expeditions, it’s no surprise that many are desirous of anti-fraud protection on the client (endpoint) for cloud. It would only be surprising if that were not also true of apps on-premises.

Anti-fraud protection is about enabling security for the “last mile” – the user – in an application world where control over devices, things, and apps in the user’s hands is not always possible. Modern anti-fraud protection is often thought of as a purely financial industry concern, but the reality is that only 25% of real-world malware is caught by anti-viruses and though it may be targeting financials with which end-users interact, like the honey badger, it don’t care if corporate credentials happen to be exfiltrated in the process. And once they’re on the open market, you can bet there’s someone who will pay for them.

The security perimeter is changing. Cloud, the disaggregation of applications into microservices and APIs, and the delivery of native mobile applications has caused a dramatic shift away from the traditional castle wall to a more mobile, “circle the wagons” approach to protecting apps. The “app” is now the perimeter, but we must be vigilant in our efforts to ensure that no component of the “app” is left out, and that sometimes means extending a perimeter around the client, even if only temporarily.

Web fraud protection isn’t just for banking any more. Enterprises concerned about the overall strength of their security posture and commitment to “always” protecting the client need to evaluate modern anti-fraud protection in terms of how it can help prevent malware and viruses and other stealth attacks from absconding with corporate credentials.