Teaching Them How to Fish… or How I Justify Spending 3 days on a 1 Hour Task
Most of my work days involve explaining things to colleagues with less experience in a particular technology or process. The goal is for them to complete the exercise or analysis with guidance, and eventually be trusted to effectively complete the work on their own. In my line of work these “things” are usually complex technical problems that require thoughtful design and precise execution. However, the guidance and solutions are anything but elusive.
When it comes to tech, the internet is rich with documentation. Anyone can Google what to look for during a manual security code review, how to invoke a Lambda function, or what benefit a given security header provides to a website. Similarly, mature companies have ample internal literature to answer questions like “what is considered sufficient evidence for external auditors?”, “how should I conduct my threat model?” or “how long should an access token be valid for?”.
So for most questions and problems that cross my desk, the technical information is readily available. And honestly, I usually feel like there’s nothing useful I can add to a published RFC or a vendor’s implementation guide. It’s a quick “here’s the documentation, here’s the guidance/commentary our team has already published, please let me know if you have questions or would like to discuss further”. And I don’t think there’s anything wrong with that.
However, the game is a bit different when assigning a task to a junior colleague, summer intern or any new joiner who isn’t familiar with the project or company’s standards. For this population, I am a firm believer in taking the long route. I believe that allocating additional time to reading, analyzing and demo’ing early on leads to more precise analysis and ultimately saves time in the long term. Beyond reviewing and analyzing much of the aforementioned published documentation, it is important to spend additional time explaining the context for each component and collating a variety of views on the topic.
Here’s an example:
Task: Assess this application for broken access control on a single API.
Traditionally, one would provide a junior security engineer:
- The URL for the application
- A set of test credentials
- Access to manual pen testing tool of choice
And send them on their way.
They’ll come back with the results, and you’ll know pretty quickly if the application is vulnerable.
However, I would provide a whole wealth of additional information so the engineer can learn more broadly about the application, the technologies used and the vulnerability. This would include:
4. Narrative architecture of the application — with a focus on the specific components to be tested
5. OWASP documentation on broken access control (IDOR)
6. PortSwigger’s “Web Security Academy” section on Access control
7. Previous penetration test reports for the application
8. Internal documentation on API structure (Swagger or otherwise)
9. Link to the code that implements the API
10. Links to recent news articles and published CVEs for this vulnerability
11. Relevant RFCs for the technology used (i.e. REST, JWT)
12. Blogs, articles and StackOverflow links covering the topic of broken auth
Coupled with an explanation of why each of these artifacts are important, and a touchpoint conversation to review any questions the engineer may have prior to executing the test, I have found this method useful and effective for completing the task. Sure, this method takes a lot longer. And it might be boring to spend a few days reading and synthesizing all the documentation. However, if time permits it, this method provides the “newcomer” (or technologists with any level of experience) with a solid introduction to many foundational concepts at once. Rest assured the next time this engineer is asked to assess a vulnerability, they will have a much easier time and will present a deeper technical analysis.
Maybe you’ll accuse me of overexplaining or overloading colleagues with documentation and information. But I still believe the upfront time investment will pay off. It has for me.
