Category: Experience Reports

Categories
Experience Reports Ramblings

Threat modelling: Don’t forget your test engineer

I am a test engineer at my current work. After watching a number of talks at Ministry of Testing I also signed up for a secondary role; Cyber Champion. Through this role I’ve been learning about many aspects of cyber security and then running brown bags for our office to help people learn more about the various aspects of cyber security and I’ve also been doing vulnerability scanning. However what I most want to talk about is threat modelling.

If you’ve not heard of it, Threat modelling, at least within the context of software, is an exercise to identify vulnerabilities within your solution. I’ve written some words about it on my Threat Agents site (will explain “Threat Agents” shortly) so I won’t go into too much detail. In short, you put together a data flow diagram then look for vulnerabilities in it. Most people use a mnemonic called STRIDE to achieve this.

If this isn’t familiar then I’d recommend checking out my Threat Modelling write up on my threat Agents site to learn more, or have a look at Ministry of Testing, OWASP or have a quick Google.

Now to the point. Many teams may approach threat modelling by pulling in their senior software engineers, those with the most experience developing the software. However this is a poor idea. Bringing less experienced people to the table could lead to attacks that are “known but unsaid” and therefore easily forgotten or other blind spots that have been learnt throughout the years.

But there’s someone else that you really should bring along. Someone who spends most of their day trying to identify the risks in a feature. Someone who has the nack of finding holesand flaws. Someone who has probably has the widest knowledge of your solution.

Your test engineer.

Next time you are threat modelling, be sure to invite your test engineers. They don’t need to have any security experience or programming background. If they have the ability to spot that “X + Y – Z = Crash”, they are likely to also spot that “R + T – U = Vulnerability”.

If you’ve not done threat modelling before then it can seem quite daunting. Certainly when I was about to have my first sessions I felt pretty anxious that I’d be out of my depth, despite having read and understood plenty on it, including STRIDE. However after completing my first session, I loved it. Not only was it a useful exercise for the business but I really enjoyed threat modelling. As a test engineer I was in my element.

To help people get over that initial hurdle and avoid the risk of setting around a table, looking at a threat model going “errrr” (what my first session would have been without a great coach), I have created a card game called “Threat Agents“.

This takes the elements of STRIDE, adds my quirkiness to them and some structure to help you get going. The game is free to download and get to print off your own copies.

Categories
Experience Reports

“Just run what was done before”

My biggest challenge when switching back to test

Before I start, a bit of background. I started at my current company as a Software Test Engineer. I didn’t really enjoy the very rigid processes that we had in place and felt it didn’t make the most of my creative ability to find bugs. I ended up switching to a couple of other roles before returning to test some 6 years later. In that time a lot of changes have been made.

Whilst not explicitly stated, my team now favour a Context Driven Testing approach to both features and user stories. How we write tests, share them and execute them varies project to project and even user story to user story.

I do like this freedom to choose and adapt my approach, meaning that if I think that more detail & structure is required, I can use that. For user stories where tests are very niche & specialist and won’t ever be re-ran, I can dramatically cut down on documentation, allowing more time for bugs.

However when I joined I was replacing the existing sole tester in the team, having been a developer in a different team. I found it quite challenging to use my limited knowledge/experience in several scenarios.

For example when picking up a fairly regular testing around appliance updates, it would seem logical to use a similar strategy as before. However I don’t fully know the context of those tests. Were they shortened due to a time scale or extended beyond the normal coverage because of risks specific to that update? Was it only manual testing because we don’t have automated tests or is looking at making this our first automated project a blind alley that has been pursued before? Why was this strategy used?

In the end, after consulting with the team I repeated the same test cases on a selection of platforms plus one extra due to a specific risky package update. We suspect that was the logic used previously. As per usual I provided my list of tests, equipment to use in a test plan for the story, which can be looked back on.

However this problem is going to continue to resurface as we try to decide the same the best strategy for this context next time. It is possible that the next person to perform these tests might not be me, or I’ve simply forgotten the thought process and time will be needlessly spent trying to figure out the ideal strategy for this context. Likely the same tests will be ran again, including the extra one that I added. This is a problem we have in a few areas.

To try to resolve the problem we discussed that to help people repeating this are of testing down the line that we should provide a rigid set of instructions on what to run etc. We’d break from CDT for these tests. Not ideal, but saves effort for whoever picks up the testing next time. A user story was created to do this.

Thinking on this matter more, this is a blunt way to “resolve it” and papers over the re-occuring mistake. What I really needed to understand previously was the logic in the previous strategy. Why these test cases? Why these platforms? Why were others excluded?

I still want to provide guidance for testers picking this up down the line, detailing the core tests that you need to run every time. However the solution is to not just have the strategy written on the user story, but to ensure that the logic and reasoning is provided for historical use. This should help the next person to pick up this testing to devise the best strategy for that context.