Monday, September 5, 2016
Human Vulnerabilities and UI
Human Vulnerabilities and UI
How to mitigate the kind of threats presented by Frank Stajano and Paul Wilson in the good article Understanding Scam Victims: Seven Principles for Systems Security? (from the Communications of the ACM, March 2011). In a generic way, it is impossible to answer that question. That is probably the reason why the authors themselves dont follow that path in that article.
In some specific domains, it is likely that one can anticipate some mitigations. Yet, this should be taken with a grain of salt: any generic advice will have generic results. When the topic is security, an answer to the same question will vary immensely depending on the context. Imagine a question like: How to make a house safe? (considering safety against unauthorized intrusions). The answer will be totally different for a house in a remote location in Alaska from the answer needed to improve security for the White House. Similarly, consider the question How to make my software safe against the principles of human behavior? That will also have very different answers for a software game than those for an ERP system.
Considering commercial systems processing records and having a workflow driver by some user-interface (non-automated), I would have the following generic advice regarding each principle of human behavior.
Distraction: ask for confirmation of any user action that may represent a threat. Increase or decrease the level of confirmation depending of parameters of the action. I particularly dislike that one cannot cancel clicks easily. Is your application placing buttons that the user could click too close one of another? If the user is doing a sequence of actions, and then stops, it is likely that when coming back some context is lost. Will the system be clear to the user regarding what was happening?
Social compliance: the problem here is that typically an authorized user for the computer system is doing something under the request of an authority outside the system. I dont see how this will ever be solved without some kind of authorization transaction involving some public identity control system. Suppose your company has an ERP system and the police shows up and demands to see such and such records. They would need to have some PINs in the court order than you could enter in the ERP system before the review of the required records. The local ERP system would not only record the event but also connect to a web service from the police/court that would authenticate the court order.
Herd principle: this is the only challenge for which I can only suggest user education. People have been able to create a housing bubble despite all the documentation and process required to buy and sell a house. People will jump over all possible obstacles one can imagine if they believe to be missing an opportunity that everyone else is enjoying.
Dishonesty: logging, warning, threatening. It works. From expense reporting systems that have clear warnings to military systems that threaten dismissal and martial court, people think twice when seeing a threat and knowing they are being watched. Now, for a scenario of junk email offering some millions in your account, I do believe that every communication system should have periodic educational messages providing examples for the sake of user education. Some instant messaging systems show good warnings regarding not sharing personal information, or following links. Yet, Ive seen no e-mail client ever that every month sends to users a summary of common scams that people shouldnt be thinking of participating on.
Kindness: the key here is to avoid the scenario in which a person would be in the situation of being kind. If people are tracked by badges, why are we still requiring them to scan the badge in a certain reader at some specific location, instead of having RFID readers in the doors? Similarly, if someone is, for example, able to logon and leave someone else working in the system, can that be avoided? Possibly requiring a webcam per system, some OS call could be invoked and, with due warning to the user, take a picture at regular intervals and do some face recognition.
Need and greed: if possible, remove the need. Ive been a system administrator and Ive had long discussions with directors of large corporations about the need of NOT filtering network traffic (yes, that is NOT). One filters a known site, and the next minute users get somehow a link to a previously unknown site, with far worse consequences than getting to the previously known site (besides the time wasted on such investigations). Ive seen scenarios like corporations that got viruses when employees used laptops that they brought into the workplace to overcome filters installed in the corporate machines. Invest on targeting the illegal, and ignore the immoral or distasteful (unless it starts affecting business results).
Time pressure: unless we are talking about a software system processing events related to life threatening emergencies, an option could be having only scheduled processing. What if internal e-mail systems in a company only delivered e-mail 3 times a day? (like 10:00Am, 1:00Pm and 3:00Pm). Probably people would think twice before writing and posting e-mail. Similarly, what if any workflow for a record only happened within specified timelines? It looks useless for ERP systems to instantaneously process records that then wait for human interaction for hours most of the time, while allowing for quick processing of illegal transactions when that is needed. I used to find strange that even the 24 hours supermarkets would close in Europe during Sunday (in some but not all countries). Yet, once you know the rules, you dont feel the pressure to suddenly buy something on Sunday any longer. You then just wait until Monday, and at times no longer proceed with the purchase that was so much needed just a day before.
These are obviously just initial ideas considering only a certain context. One would need to use significant time looking at a specific system to build a good list of threats and mitigations that would bring down the level of risk due to human behaviors.
Available link for download
Labels:
and,
human,
ui,
vulnerabilities