Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Info

Last updated 3 weeks ago - there’s been a lot of movement here and this is not yet up to date.

This reflects my understanding of current status. I am not plugged into every part of the project, and there may be more analysis or investigation that has been undertaken, that I am not aware of. As I learn more, I will aim to update this document with new information

...

  1. Unlike with Privacy, we do not yet have a published set of Security by Design guidelines to follow in development of the app. We are aware of some existing resources here, but we have not yet done any work to determine what principles exactly we should adopt.

  2. We have not yet done any threat modelling around Security. At a minimum we should look at a STRIDE model.

  3. We have performed security scans using Immuniweb - see https://github.com/tripleblindmarket/covid-safe-paths/issues/232

    Some of the issues revealed have been analyzed as not significant from a security/privacy point of view, but the optics are still bad (the report says we lin to Facebook, Pinterest etc.)

    Some of the issues revealed are very probably significant - e.g. use of HTTP, use of external data in SQL query. But some may be in reality non-exploitable - even the best scoring apps on Immuniweb tend to have several “Medium” security warnings. Work is needed to analyze each of the concerns, and fix those that are in fact exploitable.

  4. We have not yet run a scan of our iOS App

  5. We are aware of many other static scan tools for Apps, both free and commercial. Here is a list of free tools. https://geekflare.com/mobile-app-security-scanner/ Reputable commercial tools include HP Fortify & CheckMarx. The project does not currently have budget for commercial tools, but we’d like to explore whether any commercial tools would be willing to partner us at no cost, in support of our security efforts.

  6. Prior experience tells us that all of these scan reports will generate many false positives, all of which need careful analysis by developers. Therefore we believe a balance has to be struck between . “More information” is not necessarily useful if it is ful of false positives, and risks drowning out important security concerns from other sources.

  7. In addition to static analysis tools (SAST), DAST tools are available, together with penetration testing driven by a human (probably with the assistance of a wide range of tools). We have not yet looked at options here.

  8. The App is just one part of our overall architecture. The other key parts are the Safe Places tool, and the back-end systems that serve up the data about infected individuals. We don’t yet have a clear documentation of the oveerall solution architecture (we hope to soon: this will be valid valuable for many reasons). We are aware of a number of security shortcomings in the overall solution, including places where we store sensitive data unencrypted etc.

  9. Our Safe Places “Product Definition” is a work-in progress document that includes several points relating to Security and Privacy objectives for the product. Many of these are not yet met by the product today.

  10. In our discussions with Healthcare Authorities, we are seeing multiple queries about security and privacy - it is clearly a priority for them, just as much as it is for us. While they may have specific concerns, they won’t typically have deep expertise in Security, and therefore providing artifacts to them that can attest to our security would be hugely valuable.

  11. We would value input both on the points above, and also insights into what key Privacy considerations are missing from our thinking so far.

...