Abuse cases and misuse cases

Question

Are abuse cases and misuse cases for security the same? From what I have read in various sites, they appear to be same, but no where is it mentioned that they are same. Please clarify my doubt.

Answer 1

Is abuse cases and misuse cases for security the same?

Yes, pretty much.

I think "abuse" suggests more malice than "misuse", but they both amount to people doing things with your software that they shouldn't be allowed to.

Answer 2

While I agree in the main with Tom77's answer. From a security perspective abuse/misuse lead to the same consequences.

However I would also suggest that misuse cases should be used as inputs to ongoing design and implementation reviews. Try to reduce the possibility of misuse. If the user can accidentally misuse the system then they will also have a lowered user satisfaction experience.

Answer 3

There is still ambiguity between the words. A quick Google search for "abuse case testing" brings up this which states:

An Abuse cases can describe the possible misuse of an application

I agree that abuse cases are a subset of misuse cases. I also agree that abuse cases contain more malice as Tom77 suggested.

But if a line has to be drawn and a definition given:

1. A misuse case will test the application disregarding the requirements. These cases are useful to ensure that fields are properly sanitized and that errors are handled gracefully. The word 'misuse' in and of itself keys us into a few things to remember:

   • It should be the opposite of a use case.
   • It should fill in the gaps/holes left between the use cases.
   • It should not only contain functional tests, but usability tests (hence mis use).
   • From the testing perspective: we are exploring, going places we weren't told about, following our intuition, trying to improve the quality of the application.

2. An abuse case will also test gaps between the use cases, but in a fashion that will try to cause the most harm to the application and environment as possible. The goal is to cause errors, damage data, undermine stability, and call forth crashes.

   • From the testing perspective: we try to cause as much havok as we can, using any tools possible. We hate the application and want to see both it and its users/users' data destroyed.
   • If we've got a website that ranks things according to number of "likes," if we are able to edit the javascript on the page to allow us to like multiple times, the data no longer has integrity.
   • If we're testing a mobile application with a phone that has a sliding keyboard, and when the orientation of the application changes if it is open or closed, we should repeatedly open and close the keyboard to see how the application handles that abuse.

Abuse cases are destructive, and only an extremely small percentage of users will have that mentality, so a lot of times I've found that managers decide to fix them last, if at all.

Misuse cases, on the other hand, actually go about and help improve the quality of the system, and I've found that issues found during this process are fixed relatively quickly, or marked as change requests / enhancements to be fixed in the near future (which goes in addition to what Steve mentioned earlier).

Answer 4

A misuse case will test the application disregarding the requirements. These cases are useful to ensure that fields are properly sanitized and that errors are handled gracefully. The word 'misuse' in and of itself keys us into a few things to remember:

It should be the opposite of a use case. It should fill in the gaps/holes left between the use cases. It should not only contain functional tests but usability tests (hence mis use). From the testing perspective: we are exploring, going places we weren't told about, following our intuition, trying to improve the quality of the application. An abuse case will also test gaps between the use cases, but in a fashion that will try to cause the most harm to the application and environment as possible. The goal is to cause errors, damage data, undermine stability, and call forth crashes.

From the testing perspective: we try to cause as much havoc as we can, using any tools possible. We hate the application and want to see both it and its users/users' data destroyed. If we've got a website that ranks things according to a number of "likes," if we are able to edit the javascript on the page to allow us to like it multiple times, the data no longer has integrity. If we're testing a mobile application with a phone that has a sliding keyboard, and when the orientation of the application changes if it is open or closed, we should repeatedly open and close the keyboard to see how the application handles that abuse. Abuse cases are destructive, and only an extremely small percentage of users will have that mentality, so a lot of times I've found that managers decide to fix them last, if at all.

Misuse cases, on the other hand, actually go about and help improve the quality of the system, and I've found that issues found during this process are fixed relatively quickly, or marked as change requests/enhancements to be fixed in the near future (which goes in addition to what Steve mentioned earlier).