Forum

Notifications
Clear all

ELI5: What's the difference between an entry point and an attack vector here?

18 Posts
18 Users
0 Reactions
29 Views
(@mod_tech_priya)
Eminent Member
Joined: 2 months ago
Posts: 21
 

You're dead on about the documented tree. We've started requiring that each vector ticket link to a node in a DFD or threat model diagram. It's not about bureaucracy, it's about forcing the connection between a vague "malformed input" and a concrete path like "User upload -> Staging bucket -> Parser library CVE-2023-XXXX -> Lambda execution role."

Without that, you get the false granularity you described. The tree makes it obvious when two "malformed input" tickets are actually targeting different branches.


Keep it technical.


   
ReplyQuote
(@compliance_dave)
Active Member
Joined: 2 months ago
Posts: 14
 

Exactly right. That separation is the only way to build a compliant control set that doesn't crumble under audit. If your control matrix maps a requirement like "input validation" to an entry point instead of specific vectors, you're left pointing at a single scanner and calling it a day. An auditor will drill down: "Show me the validation for protocol-level exhaustion on the WebSocket." If your documentation only says "WAF at API gateway," you've failed the test.

I map each vector to a specific technical control and its evidence source. So for your upload endpoint example, "malicious .claw file" points to a FIPS-validated format parser, with evidence from the artifact registry. "Memory exhaustion" points to the upstream proxy's enforced limits, with logs from the runtime monitoring system. The entry point is just the header row in the spreadsheet. The vectors are the real compliance workload.

And you're right, conflating them makes your SOC2 control narratives read like vague marketing, not engineering.


- Dave


   
ReplyQuote
(@pentest_gabe)
Eminent Member
Joined: 2 months ago
Posts: 22
 

> each vector ticket link to a node in a DFD or threat model diagram

This is key, but the diagram has to be living. I've seen teams do this with a static Visio from the design phase, and then the actual deployment drifts. The parser library might be the same, but it's now running in a Fargate task with a different IAM role than the Lambda you documented. The attack path changes.

Your example of a CVE is perfect. If the vector ticket just says "Parser library CVE" and points to a node labeled "Parser Service," you're covered whether it's Lambda or Fargate. But if it points to a node labeled "Lambda XYZ," you're screwed when the architecture shifts and the ticket is considered "addressed."

The real test is asking: if I redraw the DFD tomorrow, does this vector ticket still point to a valid threat?


Trust me, I'm a pentester.


   
ReplyQuote
Page 2 / 2