🔄 Topic

I completed a PASTA threat-modeling exercise for a fictional sneaker marketplace mobile app. The exercise connected business objectives to data flows, trust boundaries, attack paths, and controls.

🎯 Goal

Model security risks before launch instead of waiting for a vulnerability report to explain that users, APIs, databases, and payment providers trust one another too much.

🛠 What I Did

I started with the business objectives: accounts, listings, messaging, purchases, seller ratings, and payment-related processing. That immediately identified high-value assets—credentials, personal information, transaction integrity, and availability.

I decomposed the application into a mobile client, API gateway, authentication service, application server, SQL database, and payment provider. The most important trust boundaries were user input into application logic, API requests into authorization checks, application queries into the database, and payment results returning to the backend.

The threat model examined SQL injection and credential theft/account takeover. The corresponding vulnerabilities were unsafe query construction and weak authentication or object-level authorization. I then connected them to controls: parameterized queries, strong password hashing and MFA, rate limiting, server-side authorization, encryption or tokenization, least privilege, and security telemetry.

This was a fictional training exercise. I did not test a real marketplace, scan a live API, or claim that the vulnerabilities existed in production.

🔗 Key Cybersecurity Connections

business context determines which assets matter most
a threat is not the same thing as the vulnerability enabling it
data-flow diagrams expose trust boundaries
attack trees connect attacker actions to business impact
preventive controls and detection telemetry should be designed together

🔍 Investigation Questions

Which service validates authorization for every object request?
Can user input alter SQL structure or only values?
Which component stores or handles payment data?
What logs would show credential stuffing or payout-detail changes?
What evidence would confirm the model’s highest-risk assumptions?

🚨 Detection Opportunities

Useful signals include repeated failed logins, one account targeted from many IP addresses, unusual API error rates, database syntax errors after abnormal input, impossible-travel patterns, and sudden seller payment-detail changes.

🧭 MITRE ATT&CK Techniques

No direct ATT&CK mapping is claimed for the fictional model. The exercise identifies possible application weaknesses and detection needs; it does not document adversary activity.

⚠ Challenges

The challenge was keeping the model useful without pretending that a diagram proves a vulnerability. PASTA is a way to prioritize validation. It does not replace authorized testing, code review, configuration review, or telemetry.

📚 What I Learned

Threat modeling became much clearer when I began with the business process and followed the data. The most important question was not “which security product should I add?” but “where does untrusted input cross into a component that can change state or reveal data?”

➡ Next Steps

turn the attack paths into testable security requirements
add API authorization and database least-privilege checks
define synthetic logs for SQL injection and account-takeover detection