The challenge for Day Fourteen is – Develop a test plan including security tests.
In my day-to-day work I don’t necessarily write formal test plans, but rather user stories for what I’m going to test.
When writing my user story I’d consider the following points for security:
Environment: How is this application accessed? Private network or public? If it’s private, what measures are made to stop someone from breaking in? What platform are users accessing the app from – for example, if it’s a mobile device, is the app vulnerable if they lose their handset?
Access: How does a user access what they need? What authentication methods are applicable (if any), and how robust are they? Can you sign in as a user you’re not supposed to – how?
User: “As a (type of user) I…” What type of user are you testing for – and what rights/privileges do they have? Can you upgrade/downgrade these – should you be able to?
Activity: “I want/need to…” What security implications are present with the user’s desired activity. Should they be allowed to do what they are hoping to do, how might this affect other users. What parts of the application will the user “touch” in their activity, and what security implications are involved?
Outcome: “so that I can…” What should the user expect as a result of completing their activity? What do they need to access, and what should the application deliver – is it possible to modify this?
Data: Does the user need to input, share, download or store data? Who should have access to this – who shouldn’t? How would you test this?
Thanks for reading my post and following my progress through the 30 Days of Security Testing.
Feel like joining in? Sign into the WeTest Slack group and get involved!