Fraud & Application Security: Ignoring each other is costing your business !

Hey all, it's been a while since I was able to publish an article, Q4 like all Q4 was quite the time. During that time I actually travelled to Latvia to give a talk about this specific (and next) blog post at Cyberchess.

So let's move to that one subject that I think is lacking a lot of attention in cybersecurity, which is fraud. We are starting to see some discussion about it, but it's far from enough.

Why talk of Fraud VS Application Security? Fraud teams exist in banking, gaming, retail, and insurance and have been there for a while, decades, but never or rarely were they part of the security team under the CISO/CSO. My main realization happened when I was working at DoorDash. We built a lot of SaaS applications such as gift cards, credit cards, and obviously we were processing millions of orders a day to sell items online, and this comes with fraud. People want and will find a way to abuse your systems to make money.

There are multiple types of fraud, but they usually fall between 2 main categories:

• Internal: You can control an "internal issue".
  • When your application functions or features are being abused.
    • You can have mitigation and remediation of "vulnerabilities".
• External: Factors where you can't prevent the fraud but only detect it.
  • Ex: A fraudster using stolen gift cards and using them to buy items from your store.
  • You need a process to handle these issues through your payment systems, but you can't really prevent it. Detection and mitigation exist and can be built.

For this article let's focus on the internal type, when an application has an insecure design and its features or functions are being abused for fraud.

We can summarize that type by saying your application has a lot of abuse scenarios happening because it lacks security measures (ex: rate limiting, exfiltration and bad behaviour detections, etc.), most of the time, an insecure design.

What is the root cause?

I've talked of root cause in a previous article, and we can reuse the same concept here.

Most of the time the fraud exists because it's related to a bad design from your product/designer team. Then the design is implemented by the engineering team and being abused. Other times, they is simply a lack of security measures and detection to mitigate the potential abuse, because you can't fix or change the designed feature.

Example : Login
You can't remove your platform login, but you can secure your login.
You can add rate limiting, make sure there is no SQL Injection, etc.

Bad design - the root cause

When you have a team that designs workflows for your application and designs screens and each step of what the application will be doing, most companies usually forget something... Security! Security measures or secure architecture design at the same time your product/designer team builds their application design.

This results in the development/engineering team implementing a non-secure design. At that time it's often too late to adjust the application without raising a vulnerability or having some fraud incident happening. And asking for a full design change when things are or almost are in production will simply get you pushback.

How to prevent this from happening?

Your first thought should be to shift left and train designers about security or have an application security person/DRI review designs! Yes, but that won't scale.

A better approach is to move your fraud team under the security team.
Well, that won't happen easily or just won't, you might think. True.
Cross-collaboration is the first step.

If you made it this far, please subscribe!

Proposed Approach

This approach will make your security program better, save money, and will get you noticed by leadership.

1 - Cross-Collaboration

At first, establish a bi-monthly or monthly meeting with your application security team and fraud team.

Your agenda should include something similar to:

• Review current detection of fraud
• Define if the fraud is an external or internal type
• If it's internal, continue to #2 below

When you've completed the following processes a few times, make sure to increase the cadence to weekly at minimum.

2 - Find the fraud

To review the fraud detection, the fraud team will usually have specific queries to identify abnormal web traffic or weird behaviours of customers in the application. Your team needs to understand the query, the detection, and which abuse use case is being detected.

When you understand the detection, if the detection is an internal case you need to understand why this is happening. Is it a normal behaviour of the application or really an abuse of the application?

If it's an abuse, you need to understand why it is technically happening. To do so you need:

• The queries and their outputs
• The logs related to the functions or features being triggered in that detection. It could be one or multiple.
• Know who owns this part of the application

3 - Confirm the fraud

Now that you have identified it's internal, and that you have all data to analyze the fraud, you still need to analyze the technical part of the fraud: the code.

• Contact the owner
• Sit with the owner and their team and validate the behaviour; try to understand deeper how the features and functions work.
• Get access to the code for you to also review and potentially debug

This is similar to analyzing a vulnerability with its owner.

4 - Find the fraud in the code (Find the root cause)

After your meeting(s), dig through the code and understand what is causing the issue/fraud/bad behaviour/etc.

• Find the PR that introduced the issue
• Find—if possible—the design that introduced the issue
• Find since when this exists
  • Potentially, this will require raising a security investigation to validate how long and how much was lost ($ or data) from that behaviour.
  • Identify if current security measures in the platform could have mitigated or fixed that issue:
    • Rate limiting
    • Limit of requests per user/day/hour/etc.
    • Authorization validation
      • Was it missing?
      • Does it make sense to add more granular access? (Least privilege principle)
    • Authenticate the user or customer again to access specific (sensitive) data
      • (TOTP, confirm personal information, etc.)
    • For support agents we can think of:
      • Making sure they can ONLY access the data from the user they are helping. This can be done by using the previous bullet point.
    • Etc.

5 - Recommend fix

Now that you know what the issue is and where the issue is, let's write a recommendation to mitigate or remediate the issue.

• Mitigation will reduce the fraud and save dollars.
• Remediation will stop the fraud and save even more dollars.

If possible, make sure to include multiple recommendations to achieve different levels of dollar saving and order them over time.

You can start with a mitigation, then implement a fix to remediate the issue over time. This helps reduce pushbacks from the engineering team and will also give them the time to test and implement such a change.

Sometimes these types of fraud are connected to core-design features and it can be really hard to remediate those, hence we need to also train the product/design team to think or work with the security team to reduce those potential abuse use cases.

Security is not just an expense anymore

One of the most complex issues we have in information security is having company boards invest in security, as it is an expense. The reality is that security saves money, but it's not easy to demonstrate.

But if you have fraud in your company and do a similar process to the one shown in this article... your security program will now have an official metric for REAL dollars saved.

Hope that helps, and in the next article we will talk about another approach to detect and prevent fraud risk better than queries that detect ongoing frauds.