I’m Nick, an information security consultant, a public speaker, a trainer, a sometimes software developer, and - most important of all - a dad and husband. Read more about me…
This blog is updated now and again with talks I’ve given, thoughts I’ve had, and things I hope others can learn from.
Most who have worked in an Agile team will be familiar with user stories and use cases. “As a millenial in their 30s, I want access to 90s cartoons, so I can bask in nostalgia”. Many teams go further and identify ways a system can be misused or “hacked”, and worked to prevent those to make the system secure. But not enough get past misuse cases, and work to keep people safe.
In this post - by way of examples - I want to talk about “abuse cases”, as distinct from misuse cases. In short: misuse cases are how users might unintentionally or intentionally misuse the features of your product. Abuse cases are how humans might abuse other humans with your product. The features are technically working as intended, but are facilitating abuse.
“What’s the difference between privacy and confidentiality??” It’s a question I’ll often ask when leading developer training, or when talking to potential job candidates. At first they seem very similar! Isn’t privacy just about keeping things private, and confidentiality about keeping things confidential? I like to draw a distinction that goes like this:
Confidentiality is about any piece of information, and restricting its access to only those who have a valid need. It could be personal information, or business plans, or code. It could be open to everyone, restricted to a set of people, or just one person.
Privacy is about information on individuals, and is defined in Aotearoa by the Privacy Act. It’s about collecting as little as you need, storing it securely and for only as long as needed, and only using it for what you said you’d use it for.
This post was first published on aurainfosec.com, written by Sally Vernon and Nick Malcolm. It has been slightly modified to fit this blog.
Developers creating software and applications for today’s businesses have a wide range of things to consider – from responsive design and accessibility, through to security. Add in cost and time constraints, and it’s easy to see why sometimes security can be overlooked or outright ignored until the end of the project.
It can be hard to prioritise security when everything seems to be working fine and the business wants you to be delivering flash new features. But any organisation is vulnerable to a breach, large or small, public or private – and the risk is not just related to the work of malicious attackers either! We can inadvertently make mistakes which cause security incidents.
That’s why developers need to think about security early on, and throughout the project.
Showing the latest 3 posts. Read older posts…