As lockdowns ease, states must lock up contact tracing data
As states across the country gradually ease lockdowns — and as infections spike in new localities — many local government leaders are looking to contact tracing to help track, identify and quarantine new cases of COVID-19 . To assist this effort, Google and Apple announced a security- and privacy-based framework in April 2020 to allow developers in each state to build these apps for public use.
In the quest to return back to normal however, two big questions remain: who is going to have access to this sensitive data, and how can we prevent it from getting into the wrong hands?
Data storage challenges
As we’ve seen with many of the varying state coronavirus policies, one of the biggest issues is that each state has its own privacy laws, which will undoubtedly create discrepancies and inconsistencies in how to store and protect data.
For example, will California have its own database while New York, New Jersey and Connecticut partner together in the tri-state area? Do cities such as Dallas, Austin and Houston need their own isolated databases because of population density compared to rural areas? And, as states reopen businesses and people start traveling again, will this information need to be shared across state borders?
We’ve already seen, some states rejected the Google-Apple framework and sought a different solution, and others may consider a similar path. With technologies, policies and procedures varying between states, it becomes harder to maintain security and compliance standards for national data.
While some states may incorporate strict protections against adversaries seeking to exploit contact tracing data, a lack of common protocols may leave other states more vulnerable. If attackers were able to gain access to the databases or cloud servers hosting contact tracing data in one state, they may be able to breach systems other states with similar or even stronger security in place.
Dangers of too much access
Contact tracing app data falling into malicious hands could have devastating consequences.
With access to this critical data, cybercriminals could collect an individual’s personal information — such as name, address and health records — and sell it on the Dark Web. They may be able to decipher location data and determine a person lives and works. Those exposed as having had COVID-19 could be discriminated against by their peers, workplace and insurance companies.
Individuals would not be the only ones at risk. Those responsible for the data could risk penalties if they are under the jurisdiction of consumer privacy regulations, such as the California Consumer Privacy Act.
How privileged access management can deter breaches
Any type of breach is dangerous for states and for the citizens whose data they store. However, if attackers gains the admin credentials to the server that stores critical contact tracing applications and data, the sky’s the limit to the menace they could pose. Threat actors could temporarily halt access to the contact tracing system and delete existing data, greatly diminishing the value of the effort and painting an inaccurate picture of a state’s cases. Attackers could also change the usernames and passwords public health workers, blocking them out and possibly delaying notifications to people exposed to the virus.
Fortunately, state governments can protect access to the servers, databases and cloud environments that host their contact tracing data. By securing the privileged access credentials of IT administrators, agencies can greatly reduce their chances of a data breach.
After all, nearly three-quarters of all data breaches start with privileged credential abuse. With the new processes and procedures necessitated by the pandemic, state governments must be even more laser-focused on ensuring the right security controls are in place. These controls must enable authorized users to do their jobs, while preventing threat actors from exploiting privileged accounts.
States must throw away the notion of “trust but verify” and adopt a “zero trust” mentality to protect their most privileged users. This strategy will help limit access after verifying who is requesting access, why they are doing so and the risk of the access environment. Approved users can be granted least-privilege access — just enough to do the job required, just-in-time to do it and only for the time it takes to complete the task.
To fully embrace this approach, government security leaders must take the following steps:
- Apply multi-factor authentication. With privileged accounts, agencies must know that the person on the other side of the screen is who they say they are. Passwords are no longer good enough. Two or more verification methods should be used, such as a code to the users’ smartphone, a fingerprint or facial scan.
- Make sure access is only achieved through a clean source. Organizations should ensure that privileged users are only accessing critical infrastructure through a jump host, so they don’t bring any malware or other infections from their PCs into the agency IT environment.
- Grant least privilege. Allowing the least amount of privilege possible can limit lateral movement across the network, which is how most attackers get access to sensitive data. If agencies enforce a “just enough, just-in-time” approach and zone off what users have access to, they can greatly limit lateral movement and significantly reduce risk.
Contact tracing data will be critical for gaining a better understanding of the pandemic’s spread and helping the nation recover from the pandemic. As states begin to use the data to suppress new infection clusters, it is imperative they lock down access. By adopting a zero trust mentality and protecting privileged users, the United States can make progress against COVID-19 and defend against threat actors looking for access to sensitive data.
Torsten George is a cybersecurity evangelist at Centrify.
Get your CompTIA A+, Network+ White Hat-Hacker, Certified Web Intelligence Analyst and more starting at $35 a month. Click here for more details.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .