When I was a kid just about everyone had a sandbox, and if you didn’t, you wanted a friend who did. Sandboxes were great terrain to fight your toy soldiers on and for building off-road tracks for your Matchbox cars. That of course is not the sandbox I’m talking about today, but the analogy with respect to having one – or wanting one – could very well be one in the same.
Improving health data security can be difficult as the healthcare network is susceptible to many different threats, some of which are directly related to the actions of workforce users. Despite user education, which many have dubbed inadequate, a lot of workers still make mistakes that put the entire organization at risk. This includes visiting sites that are dangerous, downloading unauthorized programs, and responding to phishing emails. Current phishing exercises, for instance, produce a click rate of over 40 percent at most organizations, and legitimate web sites have been corrupted with malware capable of compromising data, systems and networks.
Still, users’ proclivity to surf knows no boundaries. Things like “malvertising” that deliver ransomware attacks are becoming more and more prevalent. In fact, we saw several of these attacks happen just last year in healthcare, all with significant impacts.
The concept of “sandboxing” has been around for some time when talking about systems that handle classified data. However, in the last few years it has made an appearance in mainstream operating systems that we run on our desktops, laptops, and servers.
The basic concept is very simple: the operating system sets up a predefined and tightly controlled environment in which applications (such as web browsers or email clients) run. The operating system gives the application just enough access to perform activities that it deems “safe” and nothing more. In addition, the application is only given access to a predefined area of disk access that is segregated and unique to its owner (similar to a chroot environment some may remember from previous UNIX implementations of FTP and Telnet).
In its most basic sense, the sandbox environment resembles a virtualized application environment in much of the same way that host operating systems can offer virtualized servers. Because each application is given its own predefined and tightly controlled resources, breaking out of the sandbox to affect change or cause damage is significantly harder than it would be for a similar application running in a non-sandboxed environment.
For example, if an email client can only save data to a predefined location, and things that come into that location do not have access to the entire system or disk storage, then that limits a would-be attacker’s options when they are trying to take over an affected host or use it as a launching pad to attack any other host on that network.
So, sandboxing, like encryption, segregation, access controls, IDS, and DLP, is another tool we have to create an integrated and layered defense for health data security. More than ever before, health data security relies on an in-depth approach to defense, including integrated layers of protective controls and a network that is capable of detecting and responding rapidly to the threat environment.
No one solution or control by itself is going to produce complete security. At the same time, healthcare needs solutions that allow it to effectively leverage technology in a way that does not compromise agility or reach. Locking down systems or users is not feasible or advisable, and trusting them not to make mistakes is likewise not reasonable. Solutions that include sandboxing provide healthcare organizations with the flexibility to meet both criteria: flexibility and security.
Please note that this column originally appeared on HealthITSecurity.com. To access it, visit: http://healthitsecurity.com/