The Importance of Software Security for COVID-19 Tracing Apps
As countries re-open their economies, phone apps used for tracing user contacts during the day are being deployed globally. At UL, we’ve looked at some of these and found security issues with many of the apps. This post looks at how best to integrate security into the software development and release cycles of these products to help avoid security issues while still meeting the rapid deployment requirement so essential during this challenging time.
The expectation for smartphone contact tracing applications is that they must be installed by as many people as possible to be effective. In fact, a study by researchers at Oxford University's Big Data Institute said 60% of a country's population needs to be involved in making any such solutions effective. Of course, when an app penetrates into the millions, the attention of cybercriminals increases as well as heightened user privacy concerns. As patients fear public censure, the potential of over-disclosing information can be counterproductive to app adoption.
Unclear app security and privacy practices can jeopardize the adoption and effectiveness of digital contact tracing initiatives since a critical vulnerability or weaknesses could greatly reduce public confidence, leading to people not installing or using the app.
The scientific community is actively participating in the conversation and signed a joint statement highlighting that citizen trust and privacy is a crucial aspect to consider along with a design that as un-intrusive as possible.
To achieve all of these goals, it is essential to consider the privacy by design principles in the software development lifecycle (SDLC).
Building an SDLC
A robust SDLC process must consider the risks that may be faced by the software, during the entirety of its development, release and use. This starts with knowing and understanding common problems (including language-based flaws and pitfalls) and software security design best practice, as well as ensuring that all software designs are processed through an objective risk analysis process.
Considering security from the earlier design stages all the way up to production and beyond can help to avoid serious consequences such as data breaches and intrusions in production environments. If such risks are a concern — and they often are in tracing apps — plans to mitigate risks are most easily implemented at the design stage. These risks include insecure interaction among software components, risky resource management when coding, porous defenses (due to a variety of software implementation issues) and so on.
Adding security later is always harder: The secret is balancing the speed required for deployment with the level of design required to ensure a robust and adaptable system once deployed.
Some examples of publicly disclosed secure SDLC are:
- MS Security Development Lifecycle (MS SDL): Practices shared in 2008 that Microsoft used internally to build more secure products and services.
- NIST 800-64: Security considerations on SDLC developed by the National Institute of Standards and Technology to be observed by U.S. federal agencies. Also refer to NIST 800-163 - Vetting the Security of Mobile application.
- OWASP Mobile Security Testing Guide: Standards for mobile apps with a comprehensive testing guide that covers the processes, techniques, and tools used during a mobile app security test, as well as an exhaustive set of test cases that allows testers to deliver consistent and complete results.
- ISO/IEC 20734: An SDLC-method-agnostic standard that does not mandate one or more specific development methods, approaches or stages but is written in a general manner to be applicable to them all.
- BSIMM and SAMM: Although not SDLC processes themselves, they can be used as benchmark models for measuring the security posture of a solution.
All these models share a baseline of concepts — with different approaches or definitions — and can be applied to any type of solution, with some differences tied to solution type, such as mobile, cloud, web, Internet of Things (IoT) and so on. Also, SAFEcode publishes a useful SDLC reference.
But how does all of this apply to contact tracing applications specifically? Read on.
Some considerations on contact tracing applications
The application of a secure SDLC is important to ensure that the deployed code is both secure and ‘fit for purpose. At the same time, it is often a complex thing to understand and implement well. The main challenge for every organization is the friction between:
- Speed of development
- Design goals of the project
- Changing landscape in which the product is deployed
- Security threats that are always in flux.
Within this section we are collecting the main references and activities that should be considered during the development of a mobile contact tracing solution.
In an early stage, it is important — along with functional requirements — to consider the security requirements.
- Refer to local regulations: Refer to guidelines delineated by local government entities, such as the European Data protection Board: Guidelines 04/2020, on the use of location data and contact tracing tools in the context of the COVID-19 pandemic. It is important to consider local regulations such as the General Data Protection Regulation (GDPR) in Europe in which accessibly to a Data Privacy Impact Assessment document would allow more transparency. According to the European Data Protection Board (EDPB), a data protection impact assessment (DPIA) must be carried out before implementing such a tool because the processing is considered likely high risk (health data, anticipated large-scale adoption, systematic monitoring and use of new technological solution). The EDPB strongly recommends the publication of DPIAs.
- Consider best practices and security requirements: Consider the best practice recommendations such as the GSMA Privacy Design Guidelines for App Development and OWASP Mobile AppSec Verification Standard.
- Monitor the standardization efforts: The market is still fragmented with a lot of different alternatives and it is important to monitor the lessons learned by different frameworks that scientific communities and organizations are working on, such as PEPP-PT, DP-3T, TCN, PACT, OPENCOVIDTRACE, and Google and Apple collaboration.
- Provide training: Developers should, at a minimum, be aware of the OWASP mobile Top 10, as well as relevant and applicable secure coding best practices.
Once the requirements of the solution have been formalized and collected, focus on the architectural design activities. However, make sure you avoid security design flaws and integrate threat modelling activities to identify and address the security risks associated with the application. These activities serve as a way to provide sufficient protection to the privacy of the users analyzing the attack surface while not impacting the scope of the contact tracing solution.
The formalization of the risks is vital so that you can be sure each risk is covered by a mitigation strategy and that each function of the app is aligned to, and can be justified by, requirements defined in the previous step. A formalized risk management process, a relative risk register based on threat model activity (such as this example from the DP-3T initiative) and security assessments in a later stage are recommended.
Implementation decisions should be defined by clearly formalized design assumptions and reduce as much as possible the ambiguities that make it easier to introduce security-relevant weaknesses or make them more difficult to detect.
A general rule of secure code development is to automate as much of the testing as possible while reducing false positives. To achieve this, it is important to have a standard guideline (e.g., Android and iOS) covering what secure code looks like for your solution. This can then be integrated into static application security testing (SAST) tools which automatically apply the rules every time code is checked in.
In a rapid response environment like we are seeing with COVID-19 tracing apps, such automation — which can take years to properly develop — may not be so easily implemented. However, focusing on existing industry best practice, with quick wins for secure development, such as only using known good cryptographic algorithms, can still provide value.
Static analysis can only get you so far. It is important that security tests are implemented on the overall solution prior to release. In this phase, dynamic application security testing (DAST) tools can be used to identify vulnerabilities at runtime along with manual testing activities. Formal requirements are still important, often referencing back to the threat models developed at the start of the process. Many organizations find value in utilizing external agencies to help with periodic penetration testing at this stage because it brings a fresh set of eyes to the problem. This is especially important with very public deployments like contact tracing apps in which security researchers will likely take time to pick apart any applications.
At UL, we believe such security research is a good thing, but reducing the noise caused by easy to find issues is vital. In addition to the obvious security concerns with contact tracing apps, there are also valid functionality concerns. How well do they actually work? Is interference a concern, and how far does a Bluetooth signal really operate in a crowded train? A tracing app that does not work provides only an increased vulnerability surface for the users phones.
Production and operation
The work doesn’t stop with app deployment. It is important to continually monitor the risks and updated testing in light of any newly discovered vulnerabilities in third-party code modules or systems. Apps must be accompanied with a vulnerability management program, providing a path for researchers who have found potential issues to report, triage and fix them where necessary.
Providing source code that can be publicly audited can add transparency to the operation of the application, potentially reducing barriers to uptake. In addition, having a clear roadmap and patch notes can provide certainty around the future of the application.
Decommission stage and end of life (EOL)
Robust code management includes considerations for when the applications are no longer necessary or set to be decommissioned in some way. For contact tracing apps, this is vitally important as they are specifically designed to store potentially sensitive information. Understanding how this data is to be securely erased and what the process or value for this data is when updating systems to new APIs (such as those soon to offered by Google and Apple) is necessary for security.