Cloud

3/1/2018
10:30 AM
Tom Gillis
Tom Gillis
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

What Enterprises Can Learn from Medical Device Security

In today's cloud-native world, organizations need a highly distributed approach that ties security to the workload itself in order to prevent targeted attacks.

Recently, I had an enlightening conversation with a customer who works at a medical device manufacturer of laboratory diagnostic equipment. This company has thousands of medical devices in the field — visualize racks of test tubes, all computerized with a large instrument and a Windows system that's running the test equipment in the hospital.

Scott T. Nichols is responsible for product privacy and security at this company, which means it's his job to figure out how that data — each patient's name, Social Security number, and test results (basically, the most sensitive data there is) — remains protected.

The interesting thing about this situation is that these devices are computers that sit on a trustworthy network in someone else's data center or network. That means the company doesn't control the firewall, so there's a lot of risk involved in keeping its devices secure. Think about the latest outbreak of ransomware. What can this company do to assure customers and shareholders that its equipment (and everyone who uses it) is not vulnerable to these attacks?

And in this case, it's not just malware. There's the very real threat of targeted attacks. In the hospital environment, we see attacks that are directed at individual doctors, hospital administrators, and other staff members. These attacks come from within — not a bad attacker coming over a firewall. Consider this common scenario: A field tech comes in to get a report using a USB stick and that drive is infected, so even though it's separate from the network, it provides a way for a sophisticated attack to get in. Therefore, even in a closed-circuit system with an isolated network for medical devices, malware can still get in.

"The threat is people," says Nichols. "People are the weakest link." He's right: People are always the weakest link and always will be. They are trusting, hardworking, and earnest — they don't realize what they are doing is oftentimes propagating infection.

How can this company respond? As Nichols figured out, it needs a new approach to security — one that doesn't protect the network alone or rely on a physical perimeter.

Thus, the company implemented an "onion" strategy, with several layers of protection attached to an individual workload. At the heart of this strategy is the data layer, where it uses encryption of data on the device itself. Think of it as the crown in a castle that needs to be protected. Imagine building a safe for the crown inside the castle and then a moat all around the castle. Protecting the data layer is the network layer, where firewalling turns network security on and off. After the network layer is the server layer, which allows only applications that are recognized. On top of that is the user layer, where access controls allow the company to see who logged in and who logged out, check their user ID, and add password complexity requirements. They also put protections on the back end.

Why was I so fascinated with this example? It's obvious: The parallel is very similar to what the enterprise faces as it moves to the cloud. The workload is put in an environment that the enterprise doesn’t control. The traditional controls for security are dissolving and the self-service model has made it even worse, igniting a blurred separation of duties.

The enterprise needs a new model. It needs to rip a page from the playbook of this medical device company and implement the same kind of highly distributed security approach that's tied to the workload itself. I'm hardly the only one who's thinking this. A recently published Gartner report says security needs to be attached to the workload and to be multilayered — looking at data, network, computing, and users.

Migrating a workload to the cloud is like moving from one house to another: If you simply box up everything and move it to the new address, you are missing a major opportunity to clean up the old and make way for the new, an opportunity to streamline operations and to improve the effectiveness of your defenses. In the worst case, migrating a workload without revisiting the security controls can expose new vulnerabilities that were never even possible before, such as the often-experienced data leakage that comes from a misconfigured S3 bucket on Amazon that publishes sensitive data to the public Internet.  

In a cloud-native world, we have an opportunity to implement security controls that are:

  1. Fully automated
  2. Host-centric
  3. Auto-scaling
  4. Immutable
  5. Independent of infrastructure

The multitenant public cloud has revolutionized IT. For the security team, it's a new world with a new set of constraints and a new set of possibilities. The medical device community has been operating in this mindset for some time, and there are lessons to be learned from them on building a cloud-native security architecture.  

Related Content:

 

Black Hat Asia returns to Singapore with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier solutions and service providers in the Business Hall. Click for information on the conference and to register.

Tom Gillis co-founded Bracket Computing with the goal of delivering enterprise computing driven by business needs, not hardware limitations. Prior to Bracket, Tom was vice present/general manager of Cisco's Security Technology Group, leading business units responsible for ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
High Stress Levels Impacting CISOs Physically, Mentally
Jai Vijayan, Freelance writer,  2/14/2019
Valentine's Emails Laced with Gandcrab Ransomware
Kelly Sheridan, Staff Editor, Dark Reading,  2/14/2019
Making the Case for a Cybersecurity Moon Shot
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  2/19/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-8980
PUBLISHED: 2019-02-21
A memory leak in the kernel_read_file function in fs/exec.c in the Linux kernel through 4.20.11 allows attackers to cause a denial of service (memory consumption) by triggering vfs_read failures.
CVE-2019-8979
PUBLISHED: 2019-02-21
Koseven through 3.3.9, and Kohana through 3.3.6, has SQL Injection when the order_by() parameter can be controlled.
CVE-2013-7469
PUBLISHED: 2019-02-21
Seafile through 6.2.11 always uses the same Initialization Vector (IV) with Cipher Block Chaining (CBC) Mode to encrypt private data, making it easier to conduct chosen-plaintext attacks or dictionary attacks.
CVE-2018-20146
PUBLISHED: 2019-02-21
An issue was discovered in Liquidware ProfileUnity before 6.8.0 with Liquidware FlexApp before 6.8.0. A local user could obtain administrator rights, as demonstrated by use of PowerShell.
CVE-2019-5727
PUBLISHED: 2019-02-21
Splunk Web in Splunk Enterprise 6.5.x before 6.5.5, 6.4.x before 6.4.9, 6.3.x before 6.3.12, 6.2.x before 6.2.14, 6.1.x before 6.1.14, and 6.0.x before 6.0.15 and Splunk Light before 6.6.0 has Persistent XSS, aka SPL-138827.