Using Mind Maps in Application Security Testing
Make pen testing easier while delivering a better report to your client.
For testers in the application security (AppSec) arena, you know that we examine a lot of different areas, including authentication, authorization, encryption, logging, and so on, making for what’s become a staple in this job—the large lists of technical checks that grow even longer every time new issues are discovered and then added for testing. If you’ve worked in AppSec, you know that these tests can make for quite the effort, depending on the complexity of the app you’re working in.
As a tester myself, responsible for checking off every single one of those items, I know there is no getting away from the long lists themselves. Even still, I think I have figured another way help us streamline this process—so much so that we can even indulge in more thorough testing than is the market norm.
You’re probably wondering exactly what I mean. How does one streamline an assessment of a dizzyingly large web application while ensuring that the coverage meets standards? The answer lies in mapping your application beforehand (and how you go about that).
Now, you’re probably thinking that there is little to no formalized methodology or resource available that examines the role of application mapping in the test planning phase—not from the OWASP Testing Guide, nor major certifications, nor anywhere else. And that may be true, but it doesn’t mean it’s not worth it to give this approach a longer look.
What You’ve Heard vs. What is Possible
But before we get the specifics, I want to establish what we all probably know as “The Way” to test AppSec—that’s important since I’m about to introduce you to an alternative through my mapping recommendations. For the sake of brevity, let’s call The Way “Sampled Testing” and I’ll name my new method “Tracked Testing.”
Sampled Testing – A randomized approach to testing functionality.
Tracked Testing – A procedural approach to testing functionality.
When we usually approach penetrating an application, we usually just test a bit of it, right? A sample, if you will, and that’s how it’s always been. But if we’re really honest about that process, really sampled testing is:
- Haphazard in nature
- Does not ensure adequate coverage
- Potential for duplicate work
- No quantitative idea of progress
- No insight into changes between tests
Whereas, what I’m going to explain next—tracked testing—is a new approach that:
- Is procedural in nature
- Ensures adequate coverage
- Reduces duplicate work
- Enables quantifiable progress
- Allows for determinable new functionality
Migrating to a “Tracked Testing” Approach
Looking at it like that, you’re now probably wondering how to adopt a Tracked Testing approach—it’s hard to argue with something that’s a more comprehensive test but somehow makes for a more efficient process.
I said it before—the key lies in application mapping, and there are two types of tools we can use for this stage:
- Vertical Documentation Tools -- Text Editors (up and down)
- Horizontal Documentation Tools -- Mind maps (left to right)
Comparing Text Editors and Mind Maps
As you get started, choosing between these two tools is ultimately a product of personal preference, but, really, there’s a clear choice. At Schellman, we believe only mind maps can provide the type of efficiency we all crave, saving you time that you can then spend testing in a more thorough, “tracked,” process, which will impress your client more for the same amount of effort—or less.
Here are five ways mind maps can help you gameplan against web applications:
- Web Applications Are Hierarchal. So Are Mind Maps.
They enforce a hierarchy you create, and while you are responsible for maintaining the hierarchy, typically little to no work is required to do that. The same cannot be said for text editors, which are linear tools and require more personal effort on your part. - Mind Maps Provide a Better “Big Picture” View of an Ongoing Assessment.
As seen in the figures below, the mind map on the right provides a more articulated view of the application functionality, featuring clear connections between subcategories. Compare that with the text editor layout on the left—arguably, it’s much more confusing as it doesn’t demonstrate any obvious link between labels. - Mind Maps Reduce the Additional Work Created by Tracking.
Large application maps create additional work in tracking, and text editors gain this debt fast, meaning lots of scrolling for you, the tester. While still usable, it’s more inconvenient than your other option. Mind maps gain the same debt at a slower rate; furthermore, they can mitigate it (e.g., you can easily collapse the large trees so as to focus clearly on what’s more pertinent at the time). - Marking is Easier and Cleaner with Mind Maps.
Similarly, the mind map features another visual aid. Below is a comparison of a text editor versus a mind map, both with markings done. The green checks on the right stand out more clearly than having to look more closely for the “done” text on the left, creating a more efficient process and making it easier on your eyes. - Less is More - There Are Fewer Ways to Map an Application in a Mind Map.
Because there are an infinite number of options when mapping an application in a text editor, sharing these tracking documents with coworkers or clients can further require explanation, whereas mind maps are intuitive—anyone else you have to involve will have a clearer picture from the start, instead of you spending time having to explain your work to ensure their understanding.
Bonus:
If you need another reason to choose mind maps when tracking application security, I’ve also found that the left-to-right approach of a mind map provides more real estate to work with on modern widescreens.
But here’s the rub:
Text editors require constant grooming, while mind maps enforce an intuitive hierarchy and enable a more procedural method to your AppSec testing.
Ultimately, it is up to the tester to decide which tool to use – mind maps are not a requirement for application mapping, but if you’re wanting to save yourself some time and effort, I do highly recommend them.
Mind Map Tools
And of course, you might need to secure an actual tool before you begin mapping out an application. If you’ve never used one before, here are three major options to consider:
- FreeMind (FOSS)
- XMind (Proprietary License)
- Obsidian’s Mind Map Plugin (Proprietary License)
- Noteworthy: this is also a text editor
Defining a Tracked Testing Methodology
So now that we’ve got the tools and understand how they can help, the last thing we need before actually doing the application mapping is to establish the new procedure at hand. You’re going to be more thorough now in your testing—using a set method will help reduce human error and ensure consistency between tests.
To get started, below is a proposed Tracked Testing methodology—including illustrations—that can be applied to any web application. For the example’s sake, I’ve mapped the OWASP Juice Shop application using the FreeMind mind mapping tool I mentioned above.
- Create the blank application mapping.
- Designate your roles:
- Designate your legend:
- Designating a map legend will assist you and other reviewers in interpreting the map.
- Designating a map legend will assist you and other reviewers in interpreting the map.
- Manually crawl the application and label functionality on the mind map:
- Remember, we are mapping functionality, not endpoints. If instead we opted to mark endpoints, other testers may become confused as to how those endpoints are tied into the application during the testing process.
- Remember, we are mapping functionality, not endpoints. If instead we opted to mark endpoints, other testers may become confused as to how those endpoints are tied into the application during the testing process.
- Label interesting/broken endpoints and split work (if possible):
- Proceed with active testing. Mark tested endpoints:
Benefits to Tracked Testing, As Made Possible by Mind Maps
I personally have used this tracked testing approach before, and I can attest to numerous benefits I’ve seen in my work at Schellman thanks to my pivot to mind maps.
- With functionality tests being tracked rather than just sampled, I can say that application coverage is likely great.
- With duplicate work eliminated, I can likely say that the application was tested in a timely manner.
- With work split between testers, timelines are more likely to be respected.
- With endpoints being marked, the mapping serves as a clear reminder to report identified vulnerabilities or broken functionality.
- With a mapping on file for the next round of testing, we can reduce recurring debt by comparing the current test to the previous test iteration to identify and focus on new functionality.
Be Efficient, Be Thorough
As things progress within our industry, we’re all seeing how client web applications are becoming increasingly complex. Despite these changes to the applications themselves, they all still need a quality assessment of their security, and we’re the ones being asked to deliver.
But to achieve that higher class of assessment, our normalized way of testing just a sample isn’t enough anymore—a procedural approach is necessary. As a concept, that may seem like a lot more work, but we have tools at our disposal that can actually reduce our efforts as we make this pivot to a more comprehensive methodology.
Through the combination of the hierarchal nature of mind maps and an established, intuitive procedure, testing chaos in our AppSec assessments can be reduced. The “laundry basket” effect incurred by large application mappings can be tamed, reporting findings and dysfunctional components to clients can become unmistakably simple, and the surrounding anxiety for you and your client can be mitigated.
And of course, perhaps most importantly, taking all the ambiguity out of this process will result in a higher quality report—the optimal outcome for both your client and your reputation.
About Austin Bentley
Austin Bentley is a Manager with Schellman, based in Kansas City, Missouri. Prior to joining Schellman, Austin worked as a Penetration Tester for a large financial institution, specializing in Application Security and Internal Pentesting. Austin also led and supported various other projects, including security automation and code review.