Write abuser stories

[sventuerpe]

What is missing

The list of user stories in the scoping document should be accompanied by a list of abuser stories. Abuser stories outline the possible goals and resulting gains of attackers and rogue users in the same manner as a user story outlines goals or capabilities and the resulting benefits of benign users.

Examples:

• “As an employer I want to force my employees to use CWA so that my company does not become a coronavirus infection hotspot.”
• “As a criminal I want to send fake notifications (not necessarily through the app) to people so I can lure them into paying me for a fake coronavirus test.”
• “As a terrorist or saboteur I want to manipulate notifications about test results or contacts to stir up panic and create chaos.”
• “As a criminal I want to claim I am self-isolating when law enforcement is about to raid my home so that I gain time to destroy evidence.”

Why should it be included

While some obvious abuse scenarios are apparently being considered, there is apparently no comprehensive threat analysis yet. A high-stakes system like CWA will be abused and attacked and must withstand at least the most probable and the most harmful attacks. The CWA project should therefore practice security by design. Abuser stories represent threats as anti-requirements and lead to the implementation of countermeasures. Abuser stories can be handled in the development process pretty much like user stories: they can be prioritized, refined, scheduled for implementation, etc.

Where should it be included

Scoping document / backlog

[christianbrb]

@sventuerpe Nice addition 😊👍🏻 I also like your blog article.

[palmcron]

Some people collected scenarios, that could be turned into abuser stories: https://tracing-risks.com/

[kbobrowski]

I agree in principle with @sventuerpe, also read your blog post and share some of your doubts. Public discussion about use of technology to battle coronavirus was not very pleasant to follow, but we are where we are now, we can only take what's left and make the best use of it.

If abuser stories are spin in certain way by the media or misunderstood by the users it can easily kill adoption, and it is easy to come up with very improbable, but impossible to disproof / counteract scenarios, e.g. "as Google/Apple, I want to ship malicious API implementation to obtain social connections graph".

Writing traditional "user stories" is standard element of any app development, where only normal users are in scope. Abuser stories should be written by a team who did threat analysis of all possible methods and chose the one which SAP / Telekom was tasked to develop - I guess if this process was performed correctly someone above SAP / Telekom already have these stories written, and should probably be responsible for a decision on how to disseminate these stories to the public.

I'm still confused who was doing threat analysis, whether there is any public documentation about it, and if there are any documents describing decision process that led to current architecture - I can imagine that SAP / Telekom might not be in a possession of these documents, but if they can shed some light on this it would be great.

[sventuerpe]

Let me first say that I do understand there is a bit of politics involved in this project and I have no intention to blame the development team for issues beyond their control. I appreciate the openness that this here space represents and use it to raise issues I believe should be addressed.

As regards abuser stories, threat models, and security I believe openness will pay in the long run. Someone will likely find some surprising behavior of the system of way of abusing it anyway and call it a gaping security hole – OMG, we’re all gonna die!!!1 – whether there is an actual risk.

Being open about threat models and risk assessment can actually help to fend off undue accusations: if a non-issue is blown up by the media, instead of getting defensive one can then point to published information and explain why it is not really a problem or why one has chosen to accept certain residual risks.

Keep in mind that the media largely depend on experts, who they consult for assessments. If independent and potentially opposing experts have enough information to make their own assessment without doubts and they must honestly conclude that you are right after having reviewed that information, the battle should be easy to win.

In addition, publishing a high-level threat and risk analysis early invites timely feedback so that overlooked issues can be addressed before release.

[sventuerpe]

From the discussion on #70:

Denial of Service As a group of opponents or saboteurs we want to mass-report to health authorities as exposed according to CWA so that we overload them with unnecessary work and distract them from actual cases.

[jensmuehlner]

Thank you very much for your suggestion, @sventuerpe . We think, your issue is relevant but fits better the security concept than this scoping document. We will handover it to the security work stream, ok? BTW: I like your Blog Article, too.

[sventuerpe]

Is there, or will there be at a later time, a public space for security discussion or does the team prefer to work on such matters in private?

(BTW, please do not feel pressured to respond immediately to anything I say or do over the weekend or late at night. I can wait and everyone should get some time off even when the schedule is tight.)

[palmcron]

I would have expected that the security concept is part of the documentation, therefore will reside in this repository.

I guess, security discussions will pop up anyways every now and then.

[sventuerpe]

Crossref #86 – interesting threat model variant discussed there

[jendrikw]

Here are many more examples of ways to abuse the app that should be considered: http://wiki.autonym.de/index.php?title=Corona-App (German only).

[sventuerpe]

@jendrikw That looks like a rather comprehensive list.

Perhaps these scenarios should be classified into abuses that can be satisfactorily addressed by:

• Legislation. For example, abuses based on human-to-human interaction with app users („Show me that you are using CWA“) are easy to detect and report and can therefore be punished with relative ease even if they remain technically possible.
  • Regardless of whether such legislation is likely to be passed, legislation is clearly outside the development team’s responsibility and unless explicitly requested, there should be no reason to compensate for someone else’s omissions.
• Organizational or institutional controls. For example, many abuses of access-limited back-end functions such as reporting of test results can probably be addressed on this level.
• Technical controls. This group includes all abuses based on illicit and hard-to-detect activities such as rogue app or back-end instances, hacking of exposed interfaces, etc.
• Risk transfer.
• No feasible control whatsoever, if any.

[haxxbard]

Good day contributors,

your input is highly appreciated and I'm happy to share that we will shed some light on our risk assessment and therefore high-level risks and threats soon.

We will also briefly describe our security testing activities and give you some insights how the secure operations is done.

[dadosch]

"As an abuser, I want to trick people to go to shady websites (where they can enter personal details or similar) by sending them SMS or e-mails, to notify them that they 'infected'".

(This is happening in UK, https://www.theguardian.com/world/2020/may/13/fraudsters-use-bogus-nhs-contact-tracing-app-in-phishing-scam)

It should be made clear in the FAQ or elsewhere, that CWA never sends SMS or E-Mails to you.

[haxxbard]

Good day contributors,

your input is highly appreciated and I'm happy to share that we will shed some light on our risk assessment and therefore high-level risks and threats soon.

We will also briefly describe our security testing activities and give you some insights how the secure operations is done.

As promised we released today our security overview to shed some light on our risk assessment. This should give you some insights how we discussed abuser scenarios and what controls we proposed to mitigate them. You will also find a brief description about the secure operations framework.

[mynchau]

As haxxbard shared earlier, the topic of abuser stories was addressed in the security overview. In case you feel that aspects of your issue have not been addressed, you're more than welcome to open a new issue. Thanks. Best regards MC Corona Warn-App Open Source Team