![How to Work With HAR Files: A Step-by-Step Guide [With Examples]](https://media2.dev.to/dynamic/image/width=800%2Cheight=%2Cfit=scale-down%2Cgravity=auto%2Cformat=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2F5wovh8gozs51ofbg0nks.png)
As a manager in cybersecurity, how can I help my junior team members move away from rote learning?
I work in the cybersecurity division where I work, managing application security team. My team is responsible for application security architecture, pen-testing of in house developed apps, and consulting with developers on vulnerability remediation. I have a team of 10: 5 juniors AppSec engineers, 3 mid-level engineers and 2 lead / senior level engineers responsible for technical leadership and design. I have found that the junior engineers on my team have a very rote and textbook understanding of security vulnerabilities manifest in applications (code or design). They can recite textbook style various vulnerabilities like IDOR or SSRF. Yet, their ability to recognize whether either vulnerability is being exploited or its presence without explicit mention of vulnerability name is quite poor. Example: I review with junior team members in 1:1, pen tests they completed. Once they finish their demo, I asked them given Vulnerability X, what remediation recommendation do you think we should suggest to development team. My junior team members reacted with confusion and said vulnerability X was never mentioned explicitly by name. The ability to recognize the pattern before them and connect it to their textbook rote knowledge was missing, like if I was speaking Greek to them. My expectation: for junior team members to recognize the behavior they saw is Vulnerability X without the exact name being written a priori or verbatim. Yes, its appearance has changed, but not the inner workings of the vulnerability. I.e: the why of a SQL injection did not change, and never will change. My goals To have my junior engineers recognize that vulnerability behavior remains unchanged, despite name being restated in different language: e.g: if I change an application input request parameter (ID etc.) without authorization and see data I should not be able to, this is IDOR despite no name mention of IDOR. Improve pattern recognition of the various forms a single vulnerability can manifest as. I.e: rote recital is not true understanding. Question How do I improve my team members' intuitive understanding in this regard?
I work in the cybersecurity division where I work, managing application security team. My team is responsible for application security architecture, pen-testing of in house developed apps, and consulting with developers on vulnerability remediation.
I have a team of 10: 5 juniors AppSec engineers, 3 mid-level engineers and 2 lead / senior level engineers responsible for technical leadership and design.
I have found that the junior engineers on my team have a very rote and textbook understanding of security vulnerabilities manifest in applications (code or design). They can recite textbook style various vulnerabilities like IDOR or SSRF. Yet, their ability to recognize whether either vulnerability is being exploited or its presence without explicit mention of vulnerability name is quite poor. Example:
I review with junior team members in 1:1, pen tests they completed. Once they finish their demo, I asked them given Vulnerability X, what remediation recommendation do you think we should suggest to development team.
My junior team members reacted with confusion and said vulnerability X was never mentioned explicitly by name. The ability to recognize the pattern before them and connect it to their textbook rote knowledge was missing, like if I was speaking Greek to them.
My expectation: for junior team members to recognize the behavior they saw is Vulnerability X without the exact name being written a priori or verbatim. Yes, its appearance has changed, but not the inner workings of the vulnerability. I.e: the why of a SQL injection did not change, and never will change.
My goals
To have my junior engineers recognize that vulnerability behavior remains unchanged, despite name being restated in different language: e.g: if I change an application input request parameter (ID etc.) without authorization and see data I should not be able to, this is IDOR despite no name mention of IDOR.
Improve pattern recognition of the various forms a single vulnerability can manifest as. I.e: rote recital is not true understanding.
Question
How do I improve my team members' intuitive understanding in this regard?
