Incidents - mapto/sprks GitHub Wiki

Incidents are sample cases of occurring risks. (see the corresponding summary in the repository).

Incident data

Here is a short explanation how incidents are defined. Have a look at this one: https://github.com/mapto/sprks/blob/master/static/incidents/laptop_fingerprint.json The deployed file is accessible at http://orpheus.cs.ucl.ac.uk/static/incidents/laptop_fingerprint.json In it you will see the following fields:

  • id - this is a unique number identifier. No need to show it to users.
  • name - this is a meaningful (also unique) identifier. You can use it as a name and could possibly show it to users. As you decide.
  • type - this could be either "stolen" or "bruteforce". This is the type of attack that becomes possible. We might need to explain these to users in more details.
  • context - this identifies the contexts (location, role/employee, device) where the incident could occur. If a dimension is missing, it is assumed that the incident could occur under all possible values for it
  • policy - this is the policy combination that triggers the event. Ideally you would like to formulate something like "if password is less than 8 symbols". Unfortunately you can only say "if password is 8 symbols exactly" and after that hope that this would be the closest rule to trigger (because fuzzy comparison is used). In this case the condition is for biometric data (see https://github.com/mapto/sprks/blob/master/views/index.html lines 334-346 for definition)
  • description - The description part of the incident features a quote that shows employee attitude towards the policy. It is visible also before an incident occurs. It is the verbal (i.e. human-readable) explanation of the policy that causes the incident. This is both something for us to make sense of, and something to show to users.
  • event - this explains what incident happens as result of this policy
  • consequences - what is the damage that the incident causes, again human-readable.
  • risk/cost - these are relative risk and cost of the policy. When a policy that relates to this incident is used, the overall risk and productivity cost (i.e. the numeric consequences) are taken from here. There are a number of values, but many of them are just experimental. For now adding risk and cost is enough.

Possible incidents

For easier readability a list is extracted here. Numbers correspond to incident ids. Take care to make sure that is up to date when you use it by checking the actual source files.

  1. default
  2. too_demanding
  3. eternal
  4. unlimited-attempts
  5. easy_secure
  6. infrequent_use
  7. hard_secure
  8. no_pass
  9. very_easy
  10. double_nonpass
  11. easy_recovery
  12. too_hard
  13. plain_words
  14. too_often
  15. many_phrases
  16. moderately_easy
  17. touchscreen_public
  18. laptop_fingerprint
  19. no_dict_check