Security vendor: “You want to buy some detect-and-alert?”

You: “You don’t want to sell me detect-and-alert.”

Security vendor (mind suddenly weakened): “I . . . I don’t want to sell you detect-and-alert.”

You: “You want to go home and rethink your approach to 3rd party client-side risk.”

Security vendor: “I want to go home and rethink my approach to 3rd party client-side risk.”

Hmm. Maybe you can’t be quite as valiant as Obi-Wan Kenobi, declining Elan Sel’Sabagno’s offer of death sticks. Nevertheless, we hope that you can decline the detect-and-alert approach to dealing with web application client-side protection, choose a low burden approach to stopping attacks like formjacking, digital skimming and credential harvesting, and address a major gap in your 3rd party risk mitigation strategy.

Even if you can’t get the vendor to go home and rethink their approach, at least you won’t be fooled into thinking it is the right approach

The wrong approach to Magecart attacks

Knowing the marketplace for web app client-side protection as we do, we’re sure that detect-and-alert is not the right approach to dealing with third-party JavaScript attacks. Unfortunately, it is what you’ll encounter from solutions available in market – if they aren’t Source Defense. These approaches don’t solve the problem and they add unnecessary burden to your already overburdened Security teams.  

To begin with, detect-and-alert is only the first part of the equation; the last part, response, is all on you. Was the alert really a problem? Was it a false positive? How likely is the threat to harm you? Which of your websites are affected? Do you need to react now, or can this wait? Detect-and-alert doesn’t prevent the problem from arising in the first place, which is the solution you want.

Next, the cost of this approach is significant when you measure it by manpower and the potentially high number of alerts your SecOps team has to birddog. Not to mention that it will also be necessary to change a configuration or modify code to deal with the threat – pretty difficult to do when you consider the sheer number of 3rd parties involved in your website, their use of dynamic code, etc.

Finally, in an era where massive cybersecurity labor shortages exist, you’re probably not looking to burden your existing staff with yet more tasks. Yes, client-side threats are urgent, but they don’t have to be addressed with the same old failed (and untenable) strategies of detect-and-alert. Where do you want to focus your scarce resources?

The din of alerts

Research conducted by Forrester Consulting for Palo Alto Networks helps explain why you don’t need more security products sending you more alerts.

  • The average SecOps team receives more than 11,000 alerts per day
  • More than half of the security analysts surveyed state that they are unable to keep up with the security alerts they receive on any given day
  • On average, there’s enough manpower to manually review or triage about one alert in five
  • More than one in four (28%) alerts are never addressed by an analyst because of high volume
  • Almost one-third of all alerts are false positives

Is yours a financial services company? Then the din of alerts is no surprise to you. A survey of bank security chiefs by Ovum found that more than one-third (37%) of banks receive more than 200,000 security alerts a day. Cheer up: if you had 1,000 security analysts, each one could devote about two minutes to each alert.

Preventing attacks with sandbox isolation and reflection

Of course, you wouldn’t implement a cyber security product just on a whim. You’d exercise care in choosing a path to protect your website and all the sensitive information your customers and users enter on it.

That’s why we urge you to be careful in evaluating your approach to web app client-side protection. Even some of the smartest analyst firms are suggesting you look for solutions that provide the ability to detect-and-alert because so many solutions in market take that approach – they’re getting it wrong but you don’t have to.

But we’re biased. Source Defense is built on preventing attacks instead of only detecting them and peppering you with alerts. Our Platform uses real-time sandbox isolation and reflection to prevent client-side attacks that originate with third-party vendors, plugins and applications. Our customers tell us, “As far as easy wins in information security, Source Defense is a gem.”

Do the math. You’re already struggling with burnout on your InfoSec and SecOps teams, and things like log4j only make matters worse. Your analysts have a zillion priorities, and you’re having trouble filling your current job openings. So, you know that the solution can’t add to your team’s burden. It needs to prevent attacks out of the gate and avoid putting more strain on your human resources.

The detect-and-alert approach to dealing with Client-side attacks costs your business money, time and, frankly, leaves you majorly exposed to this 3rd party risk. Source Defense stops these attacks in their tracks with the only approach that makes sense – period, full stop. Find out more with a demo of the Source Defense solution.

PCI DSS 4.0 makes client-side security a priority.

Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.

Scroll