Threat Intelligence Usage in API Security and DevSecOps with Snap Finance Chief Security Officer Upendra Mardikar

the CYBER5

In episode 73 of The Cyber5, we are joined by Snap Finance Chief Security Officer Upendra Mardikar.

We discuss how threat intelligence is used in application programming interface (API) security and development security operations (devsecops). Any organization building an application has data or user-generated content as the primary product. Once connected to customers, consumers, clients, or partners there is a new set of security considerations generated.

The API serves as the software intermediary that allows two applications to talk to one another. It's bad enough if an attacker exfiltrates sensitive data, but imagine if they are able to gain visibility to see who is querying for the data held in the application. Imagine if Russia can see who is querying certain individuals in a credit bureau data set. That's a whole other set of problems organizations face.

As we've talked about in previous podcasts, devsecops is the security of protecting the software development lifecycle (SDLC). We talk about why API security should be added to the wider MITRE ATT&CK framework and further discuss the impact of organizational immaturity as it relates to tackling API and DevOps security.

Five Key Takeaways:

1) APIs are at the Forefront of Digital Transformation and Must be Protected

APIs go north/south between the company and customers and east/west establishing interconnectivity between different applications within the enterprise. A giant need exists to go “outside the firewall” to observe threats that are attacking APIs because they are fundamental to many enterprise functions, regardless of industry.

2) API Security is Very Immature in Enterprise

Many security practitioners focus on north/south protections of APIs and implement firewalls and DDoS protections to keep intruders out of the environment. However this is a myopic strategy because it does not protect against lateral movement and privilege escalation when an attacker compromises perimeter security. When perimeter security is compromised, protecting east/west APIs becomes critical. We are seeing trends around Zero Trust.

Zero Trust is based on the premise that location isn’t relevant and users and devices can’t be trusted until they are authenticated and authorized. To gain security from a zero trust security model, we must therefore apply these principles to our APIs. This aligns well since modern API-driven software and apps aren’t contained in a fixed network — they’re in the cloud — and threats exist throughout the application and infrastructure stack.

An API-driven application can have thousands of microservices, making it difficult for security and engineering teams to track all development and their security impact. Adopting zero trust principles ensures that each microservice communicates with the least privilege, preventing the use of open ports and enabling authentication and authorization across each API. The end goal is to make sure that one insecure API doesn’t become the weakest link, compromising the entire application and data.

3) Integrating API Security into the MITRE ATT&CK Framework

API Security is different from traditional application security (OWASP), which is integrated into the MITRE ATT&CK Framework along with attacks on servers, endpoints, and TLS, etc. API security focuses more on the potential attacks of exposed, internet-facing microservices in addition to the business logic. API security primarily focuses on:

• Users: The most common API vulnerabilities tend to be centered around issues with an authorization that enables access to resources within an API-driven application.
• Transactions: Ensuring that transport layer security (TLS) encryption is enforced for all transactions between the client and application ensures an extra layer of safety. Since modern applications are built on microservices, software developers should enforce encryption between all microservices.
• Data: It is increasingly important to ensure sensitive data is protected both at rest and while in motion and that the data can be traced from end-to-end.
• Monitoring: This means collecting telemetry or meta-data that gives you a panoramic view of an application, how it behaves and how its business logic is structured.

4) Improvements for Threat Intelligence Against APIs of Applications

Threat intelligence providers need to go beyond the features of user stories, but also be able to alert and automate when malicious actors are targeting the microservices of APIs as the business logic of these APIs are more central to business operations.

5) Threat Intelligence Should Try to Integrate with Threat Hunting to Conduct Proper Malicious Pattern Matching, Reducing False Positives

Pattern matching to detect malicious behavior over legitimate user traffic has evolved over time:

• Netflow: track network traffic emanating from the routers to the endpoints
• Applications: track application traffic to deter anomalies of authentication
• Data: track data flows in motion and at rest in the data lakes
• Devices: mapping devices to determine proper asset inventory
• Users: tracking user behavior such as off business hour queries to sensitive databases

The industry still needs solutions that detect and correlate these behaviors at scale because thus far this has been extremely fragmented.