The last few lessons all share a common theme: DRY (don't repeat yourself). Figure out the busywork and repetitive tasks you're doing over and over again. Then, let Dradis handle them for you. At the end of the day, that's what Dradis was built to do.
In this 5th lesson, we're going to continue on this theme by exploring another repetitive behavior we see many teams engaging in. Imagine you're out there on a mission to perform a security assessment of one of the satellites around Caprica's orbit. A cursory glance at the exposed communications interface reveals the same old "outdated encryption protocols" problem that is pervasive across 80% of the satellites orbiting our colonies. What do you do?
Option A:
You meticulously think about this problem that you've seen exactly 12,453 times over the last 6 months.
You create a brand new description of the situation providing as much context as possible. You add a lengthy discussion about possible remediation actions, making sure you include specific details for this satellite's make and model (and including footnotes for minor differences associated with the patch-level version of its firmware).
Option B:
You spend 30 seconds thinking about that one mission about 3 months ago where you found a similarly poorly configured satellite.
You spend another 15 minutes trying to find out where the report for that old engagement might be located.
Finally, you spend a couple more minutes opening the old report, copying & pasting the relevant chunk into your new report, and reading it sideways to verify you've scrubbed the specific details about the client, project, and satellite address in question.
Of course, it's a trick question! Both of these alternatives have their own risks:
For Option A:
If you rewrite each description and recommendation each time, you're likely to forget details (like a specific Reference, or some information you recently read about that's relevant to this vulnerability class, but that you forget in the heat of the moment).
You're also wasting valuable time. 85% ~ 90% of what you write will be exactly the same across all instances of this problem, with only 15% ~ 10% being specific to this particular situation.
For Option B:
Along the same lines as Option A, besides being against fleet regulations, copying from an old report can introduce mistakes.
It's also inefficient. Think about the time and effort it takes to carefully remove all the sensitive information from the original source.
You can also propagate typos or copy from a version of the recommendation that is no longer in line with current best practice recommendations.
For these reasons (plus others), we recommend you equip your ship with a library of reusable vulnerability descriptions. Never again spend an extra minute rewriting the description of an issue you've found before, or risk data leakage by copying and pasting from an old report. Create, grow, and maintain your own list of vulnerability descriptions and save yourself some time (and headaches!).
There are the two main challenges with reusable vulnerability descriptions:
The more your Library of reusable vulnerability descriptions is integrated with your other tools, the higher the chance you'll actually use it.
Here are some common options to get started with your own Library:
It's not ideal, but it's better than nothing! Start storing findings today in a file (Word, Excel, etc.) and soon you'll have dozens of entries to draw from. This can work if you're testing by yourself. But, if you're part of a team, you'll most likely need a shared issue library that's accessible by everyone.
The next step up from a file, a wiki will let you have revisions, audit controls, and if you're part of a team it will let you share your library with others.
Check out Dradis' dradis-mediawiki add-on. When loaded into your Dradis unit (remember how to load new add-ons from Lesson 1?) it will create a new search form inside the "All Issues" sidebar so you can run searches against an external wiki instance:
Remember that you'll have to configure the connection between Dradis and MediaWiki, using the Configuration link in the header. After you finish configuring, enter your search string, hit Enter, and presto! Choose from the search results to add the correct entries into your project.
Wikis are a great option for small teams or ships experiencing budgetary constraints. But, their convenience comes at a price. These are some common pitfalls crews experience when relying on a wiki to maintain their library:
The wiki can easily grow uncontrollably and become messy.
Your team needs to agree on a template for your vulnerabilities Otherwise, all of them will have a slightly different structure.
It is somewhat difficult to organize or index everything that’s in the wiki. Keeping the wiki in good shape requires constant care. For instance, adding content requires adding references to the content in index pages (sometimes to multiple index pages) and categorizing each page to be easy to find.
There is a small overhead for managing the server / wiki software (updates, backups, maintenance, etc.).
It's doable, it just requires a bit of work and determination.
Unlike wikis, these tools were purpose-built to manage your testing issue descriptions. Information is well structured, content is easy to update, and in general they're created with the needs of IT Security professionals in mind (or if you're creating your own tool, with your own needs in mind!).
Dradis Pro ships with one such vulnerability library management tool, the IssueLibrary add-on. But, if you or someone in your crew has software craftsmanship skills, you could create your very own library system to fit your workflow like a glove.
No matter what system you end up adopting, the important takeaway is that you need to start building up that library as soon as possible.
Apart from everything we've covered above, other benefits of creating and maintaining a curated library of vulnerability descriptions and recommendations include:
Continuous improvement: once you've got version #1 of your vulnerability description, it's easy to revisit and improve it. For example, when new information becomes available that's relevant (e.g. network browsers deciding to sunset support for certain protocols), you can quickly update your mitigation advice.
Consistent explanations and advice: don't risk the same client receiving two different reports with slightly different versions of the same vulnerability description or recommendation.
Consistent risk ratings: have you ever been in a situation where a client complains about two projects or teams providing different risk ratings for the same issue? Oh yes, it's nasty!
Templates kick-start your projects with a baseline structure. Testing methodologies create consistency and quality. Combine these with a library of reusable vulnerability descriptions and you're guaranteed to see a very significant positive shift! Get ready to see a change in the ratio of time spent testing vs. time spent reporting going forward.
Today's homework:
Lesson 5 Worksheet: How do you organize your vulnerability descriptions?
Your email is kept private. We don't do the spam thing.