Hi all, I’ve added a new post to my blog “AppSec Untangled.” This post breaks down what AppSec engineers actually do, the value they add, and how they help teams define what “secure” means for the systems they build. It also covers the processes, tools, skills, and tradeoffs involved in running an effective AppSec program, without turning AppSec into a bottleneck.
Here is the link, Hope you find it useful!
1 Like
Hi @Mohamed_AboElKheir, interesting how your take on “Did we do a good job?” is “Verification and testing”!
The German TMC DACH chapter has an upcoming session about “Did we do a good job?” and we are looking for various facets of answers to that question.
Can you share some more thoughts on what exactly should be verified and tested?
Yeah, I think “Did we do a good job?” could mean multiple things, but one important aspect of it is “Are the mitigations implemented and working as expected”, and we need testing and verification to answer this question. In other words, one of the outputs of the threat model should be a testing plan to cover the mitigations of the threats identified, and this could include code reviews, pentesting, use of security tools like SAST depending on the context.
e.g. Threat: Broken tenant isolation allowing one customer to use the endpoint to access the data of another customer
Mitigation: The endpoint code always verifies the authenticated caller user id is a member of the input tenant id.
Verification: Use Burp to test passing a tenant id the user is not a member of and make sure we get 403 response code.
Continuous Testing: Add an integration test to verify the same behavior doesn’t change in the future
In my opinion, one of the main values of threat modeling is that it defines security, in a way that can be verified and tested. Otherwise, we risk the threat model becoming just a document created and forgotten.
2 Likes
Thanks for sharing, @Mohamed_AboElKheir !
Yes, talking about how the threat model “defines security”, I liked the definition you had in another occasion: “Mitigations are what needs to be true for the system to be secure.” (Hope I quote you right)
So that’s
(1) have the “right” mitigations
(2) test that they are working
= secure
Your article has that as
(1) define “security”
(2) enforce “security”
I understand your approach to (2), how would you verify (1)?
yes, that is correct. So regarding (1) or verifying we have the right list of mitigations, this is more subject to the interpretation and experience of the security engineers and developers working on the threat model, but can be improved by:
- Using a threat library for the most common and important threats and the mitigations that were agreed for them before, and adding some automation to auto add relevant threats.
- Using feedback from security tool scans, pentests, bug bounty reports, .. etc to update that threat library and/or individual threat models.
This way threat models become more uniform and complete over time. This is one of the things that doesn’t have to be perfect at the start when you add a threat modeling process, but improves over time with the right processes.