Endpoint Security

Top Five Pitfalls When Considering Client Side Security

When looking to secure online applications and protect them from fraud, enterprises have traditionally turned to preventative and detective controls on the server side.  In other words, policies, alongside data, logs, and transaction information have long been a go to mechanism for mitigating risk from security breaches and fraud events.

<p><span><span>When looking to secure online applications and protect them from fraud, enterprises have traditionally turned to preventative and detective controls on the server side.  In other words, policies, alongside data, logs, and transaction information have long been a go to mechanism for mitigating risk from security breaches and fraud events.

When looking to secure online applications and protect them from fraud, enterprises have traditionally turned to preventative and detective controls on the server side.  In other words, policies, alongside data, logs, and transaction information have long been a go to mechanism for mitigating risk from security breaches and fraud events. In recent years, many enterprises have begun to consider the question of whether or not they should look at the client side environment as well, and, if so, how exactly they should look at it.

The question of the importance of the state of a client device is a debate that has been around for a few years in the security field. On the one hand, client devices are a big unknown and, in some cases, come infected with malicious code (e.g., banking Trojans) or are vulnerable to phishing attacks, malicious JavaScripts, and other such client side attacks.  On the other hand, policing client devices is an extremely complex undertaking, and beyond that, infected or vulnerable client devices aren’t necessarily what is responsible for introducing fraud into an enterprise. 

While I believe that enterprises should take a balanced, calculated, and measured approach to client side security, I would like to offer a few thoughts to consider while doing so.  Here are the top five pitfalls that enterprises may encounter when considering client side security:

1. Playing whack-a-mole: Banking Trojans, malicious JavaScript, and other client side attacks are plentiful and abundant. They will also be around for quite a while as far as I can tell. As such, once an enterprise opens the Pandora’s box that is the client side, it may soon be overrun. Of course, each enterprise needs to decide for itself what, if any, action it will take each time a client device is discovered to be accessing the online application from a compromised environment. If not designed wisely, any processes around this can soon lead to a never-ending game of whack-a-mole that will bury the security and fraud teams.

2. Losing focus on risk: It is important to treat information about a compromised client side environment as just that – information. While that information may be helpful in understanding the overall risk to that particular client’s accounts, in and of itself, it is not reliable as an indicator of risk. Why is that so?  With so much compromised PII and stolen account information out there, there are many ways for a fraudster to accomplish Account Takeover (ATO). In other words, a compromised client device doesn’t necessarily mean that ATO will occur, and it doesn’t necessarily mean that a fraud loss will be incurred by the enterprise.  That determination requires a number of different data points, with one of them being the state of the client device. Forgetting this important point can cause the enterprise to lose focus on risk.

3. Losing focus on transactions: When looking to mitigate risk and reduce fraud losses, it is important to remain focused on transactions. It is far too easy to get distracted by other data points that seem interesting but don’t, in and of themselves, tell us whether or not a specific transaction is legitimate, suspicious, or fraudulent. Helpful information on the client device can add to our ability to determine whether or not a transaction is fraudulent, but it is not sufficient to make that determination without other important data points.  If we lose sight of this focus on transactions, it is far too easy to fall into a never-ending trap of false positives and noise that will soon bury us.

4. Losing focus on sensitive data: When an enterprise opens the door to the client side, there is often an overwhelming amount of data to look at. All of that data, if not properly analyzed, categorized, and triaged, may lead to an abundance of alerting – most of it with little to no value. It is important to remember what is truly important – sensitive data that may find its way into the attacker’s hands and the potential to add, modify, and/or remove transaction data. It is also important to remember that although Magecart attacks are perhaps the most common method used in this type of attack, they are not the only one. As enterprises begin to look at the client side, they need to remain focused on sensitive data to avoid being overrun by other, less relevant data.

5. Forgetting user experience: While, in the effort to combat fraud, it may be tempting to institute strict, draconian measures, it is important to remember that those measures may not always result in reduced fraud. They may, however, negatively impact the user experience to the point where they cost the organization in lost revenue. It is important to institute proper controls to protect online applications from fraud, but it is also important to remember that a user experience riddled with friction will cost the enterprise in other ways. When an enterprise forgets this important balance, it creates a new risk – that of leaving potential revenue for competitors to claim.

Advertisement. Scroll to continue reading.

Related Content

Copyright © 2024 SecurityWeek ®, a Wired Business Media Publication. All Rights Reserved.

Exit mobile version