Tag: security

Categories
Experience Reports

Challenging myself in Security

Over the past 2 years and the past year in particular I have been learning about cyber security. Whilst I have spoken a lot about threat modeling and even created my own card game (see threatagentsgame.com), I have also been learning a wider area.

I recently took part in a tournament by Secure Flag (courtesy of my work). It was quite interesting to get a more practical learning experience in how a lot of the vulnerabilities that I’d heard about worked in practice. Much of it was focused on coding (not my strong suit) and if it wasn’t for being stumped on a javascript based framework that I hadn’t heard of, let alone used, then I would have got perfect points – so that was pretty cool.

What I most enjoyed was some of the ‘QA’ exercises and also how I was testing my code based exercises. The platform would spin up a VM/container that you can use via the web browser. It would typically contain a browser, Visual Code (aside from QA activities) and Postman. I was then typically using Postman to make my attacks and also write tests to verify the fixed environment.

So why am I wittering about this?

Much of the attacks that I made using Postman, or XSS injection etc, weren’t all that different to testing that I might perform ordinarily. Many people will be testing APIs using Postman and used to inserting “dodgy” values to try and break an API, or web form, therefore is it really a stretch to use SQL injection or XSS injection?

Quickly I’ve learnt that adding some security/pen testing to my toolkit is actually pretty straightforward and not different to typical exploratory/destructive testing that I might perform. In fact some of the actions that I performed were things that I might have done in the past. When, as testers, we try and circumvent the intended rules of the system, we are trying to perform elevation of privilege attacks. When we suspect a crash, we’re performing denial of service attacks. When we try to unleash chaos by meddling with data, we’re performing tampering attacks.

Security testing isn’t some special skill for people with fancy qualifications. It is testing. It is what I do.

Note: If anyone reading this is curious then check out OWASP Juice Shop. It is free and in my brief play with it, it is quite fun!

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.