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
Privacy is a core value for the project - we are explicitly setting out to build a Privacy-first contact tracing solution. Security & Privacy go hand in hand, since if we are not secure, we can’t ensure privacy.
Hence Privacy & Security are absolutely critical, and we want to hold ourselves to, and be held to, very high standards on these aspects of the solution.
At this point in time, we are not where we need to be on either, but we have identified this, and now we consider it an top priority to address this.
One of the challenges in moving forward with Privacy & Security is that we don’t necessarily yet know what all of the problems are. Therefore we are looking to develop a strategy for how we could develop as full as possible an understanding of what all the issues are, and this is a priority even over fixing the points we do know about, since the things we already know about may in fact prove to be minor points, relative to some as yet unknown items.
As some orientation for development of this strategy, here is an outline of where we are currently on Privacy & Security.
Privacy
We have a set of Privacy by Design principles for the project: https://t.co/m7K6I3XUUt?amp=1
We may not have enough training & policy in place to ensure that these are being, and have been followed rigorously.
We have an identified list of Privacy concerns, contributed by a community of software testers with strong interests in this area, outside of the project. We are working through analysis of these.
Safe Paths Privacy & Ethics concerns from Twitter discussion with Software Testers - April 17 2020We believe that list is incomplete, and we want to work to compile a more detailed list of privacy exposures to address.
We have recently become aware of this standard: https://contacttracingrights.org/ We are not yet signatories, but should expect that our goal is to become signatories, and should align with these standards at a minimum.
We would value input both on the points above, and also insights into what key Privacy considerations are missing from our thinking so far.
Security
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.
We have not yet done any threat modelling around Security
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.We have not yet run a scan of our iOS App
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.
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.
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.
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 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.
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.
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.
We would value input both on the points above, and also insights into what key Privacy considerations are missing from our thinking so far.