In episode 72 of The Cyber5, we are joined by DoorDash Application Security Manager, Patrick Mathieu.

We talk about threat intelligence's role within applications security programs, particularly programs focusing on fraud. We discuss the importance of prioritization between what could happen, as often seen in penetration testing, and what is happening, as often seen with threat intelligence. 

We also talk about the different types of internal and external telemetry that can be used to drive a program and discuss the outcomes that are critical for an application security program to be successful. 

Three Key Takeaways:

1) Application Security Overlaps and Threat Intelligence Shortcomings

Fraud programs exist to save money and application security programs exist to discover and mitigate cyber vulnerabilities. However, most of the same problems are derived from the same weaknesses in the application architecture during the software development lifecycle (SDLC). 

Any application development team needs to know the following:

1. Attacks: Understand the threat, who is attacking, and what they are attacking. The threat could be the server, the client, the user, etc. 
2. Custom Angles: A fraudster is always going to attack the business logic of an application, the custom rules or algorithms that handle the exchange of information between a database and user interface.
3. Obscurity: The threat will not likely be in the news, such as a ransomware group. As a technology company grows, an application will gain interest from fraudsters who will try to abuse the application. 

Threat intelligence falls short in collecting against these actors because it’s so specific to business logic and not an organized crime group with greater notoriety or known tactics, techniques and procedures (TTPs). 

2) Common Vulnerabilities in Application Security Pertinent to Fraud

1. While injection attacks are still common, the most common application vulnerabilities are fraudulent authentication attempts and session hijacking. Microservices (token sessions, for example) are common in applications. However, it’s very challenging to know who is doing what in the application - for example, knowing whether it’s a consumer, an application developer, or fraudsters. 
2. Many companies do not have an active inventory of asset management, particularly with their applications. 
3. There is little visibility for analyzing the logs on the Web Application Firewall (WAF). Every application is different and understanding what is normal versus fraudulent takes time and modeling to focus on who is attacking business logic for fraudulent gains. 

3) Application and Security Engineers Must Communicate

1. Security champion programs are critical to getting application and security engineers to communicate in a way that articulates what is normal in an application. If this collaboration does not work, the attackers will be able to collaborate quicker to execute. 
2. Adoption rates of application engineers are a better metric to monitor versus showing remediation of vulnerabilities.