Ransomware and the IoT: Q&A with Brett Kelsey, VP and CTO for the Americas, Intel Security Group



Can we overcome our tendency to put function and availability ahead of security?

At the close of last year, which the December 2016  McAfee Threats Report suggested might be dubbed “The Year of Ransomware,” Intel Security Group’s VP and CTO for the Americas, Brett Kelsey, spoke with Embedded Intel Solutions. Kelsey offered his insights on one of the threats the Report highlighted, ransomware, its effects on automotive and other sectors, and related topics.  Edited excerpts of our conversation follow.

Embedded Intel Solutions: What should the embedded engineering community know about one of the cyberattack species called out in the latest quarterly McAfee Threats Report, ransomware?

Brett Kelsey, VP and CTO for the Americas, Intel Security Group

Brett Kelsey, VP and CTO for the Americas, Intel Security Group

Brett Kelsey, Intel Security Group: When you look ransomware’s proliferation, including attacks we’re starting to see more of, those based on proof-of-concept ransomware code, and what that means to the world of IoT, you start getting into things like the potential for ransomware to exist on the embedded systems and even to take over particular systems.

We demonstrated this at our FOCUS 16 Security Conference, where we took a car system and hacked it to show that we could put ransomware on it. Whether you are an ordinary driver or you happen to own a trucking fleet, or whether we’re talking large business or individual person, ransomware attacks play out in a similar fashion: We’ve hacked your car and put ransomware on it, meaning you now must pay a certain amount of money—in the case of our demonstration at FOCUS it was one bitcoin, the equivalent of $700, to start your car back up.

Embedded Intel Solutions: How is ransomware affecting sectors in addition to automotive?

Kelsey, Intel Security Group: The medical field has been hit very hard by ransomware. Today, attacks on hospitals are going after their traditional IT systems. But their systems are inter-joined. The reporting component that you get out of a defibrillator or a heart monitor in some cases reports into a standard computer system, and if the standard system isn’t functioning, you can’t continue to perform healthcare.

Already, patient care has had to move from one hospital to another because of ransomware. And next generation ransomware is not going to focus 100 percent on attacking traditional IT; it’s going after the true IoT space. We’ll see more attacks directly into the IoT space.

The effects of such attacks could mean, for the Industrial IoT sector, that fluids at a factory might cease flowing through pipes that they should be traveling through, or start flowing through pipes where they do not belong. For the Smart Grid sector, hacking the systems that control power management could ultimately affect the grid itself.

“]Figure 1: Automotive is one of the sectors which can be harmed by ransomware attacks. [Courtesy Intel Corporation]

Figure 1: Automotive is one of the sectors which can be harmed by ransomware attacks. [Courtesy Intel Corporation

Embedded Intel Solutions: What approaches to the ransomware problem you are describing will be most effective, and which less so?

Kelsey, Intel Security Group: There is a notional concept that we are going to be able to protect the devices themselves down to the device’s chip layer, and we don’t believe that is going to be effective.

There just isn’t enough form factor that sits down at those chips. On the industrial side of the fence, you could have one particular chemical flowing through a pipe, and then that valve shuts off, and the next opens, and a different chemical is flowing through. And the valve itself, that’s automated. It’s IoT-controlled and has no idea what’s going through it. In fact, it doesn’t care. It just knows that it’s either open or it’s closed. And when it’s open it needs to know and report how long it is open, how wide it opened, and when it’s closed.

What must be baked into the chip is the ability to include attestation so that we can know what the device is doing, if it is doing it properly, and if it still is exactly the type of device that it is supposed to be.

Say for example, you are a coffee maker manufacturer. You want your IoT-capable coffee maker to act like a coffee maker, not like a different IoT-based “Thing.” And so you need at the very least a reporting component that says: “Yes, I am what I say I am, and I continue to attest that I am valid and functioning the way I am supposed to be functioning.”

That is about as much as you can expect at this moment from the IoT-related space, which means addressing more complicated security concerns requires adding some sort of an assistant. In our world that is cloud assistance, and now we are starting to see the cloud make large-scale analytics feasible. And that in turn will make it possible to provide the right level of feedback to the various IoT- or machine-based devices themselves. We’re going to end up with that variety of connectivity—with the capability of going from the device itself straight to a cloud-based attached management and security platform, which will then do all the heavy lifting.

Embedded Intel Solutions: Please speak a bit about the intersection of the worlds of ransomware and machine learning.

Kelsey, Intel Security Group: From a developer perspective, steps can be taken now in the course of device development to put in the capability that will make it possible to start exercising future technology.

Machine learning as it exists today is still a fairly new thing. Several organizations have started on some form of capability, but it’s still got a long way to go with regards to its true capability. That said, that should not slow down any developer from adding the hook components into the device manufacturing process they have today, and the code, so that any current and/or future security technology can be leveraged as soon as that capability comes on line.

Embedded Intel Solutions: What should the checklist be for the developer who needs to put in those hook elements?

Kelsey, Intel Security Group: At a minimum, the developers should be taking a look at all of the future function components that exist in their particular device or process that they are developing for. And as they are doing that, put the capability to provide attestation for each of those functions to say that they are (or are not) working as prescribed. That reporting capability can then be grabbed from a third-party solution of any kind, and then dealt with in the manner of which the third-party solution is capable.

Whether it’s a medical device looking at various medical analysis components, a smart grid component looking at the power grids, or an industrial control monitoring gas or water flow, each one contains many functions. And each of those functions must be mapped out. What’s also needed are capabilities to validate that those functions are working—that the device is functioning as normal—all the capability must be able to be grabbed from a management system that will continuously monitor the correct working state of each of the devices.

And then, at the same time, if you can take it to the next level (it depends upon room in the embedded component) you gain the ability to add true security protocols and encryption on the device side of the fence, so that your communication protocol can also be secure end-to-end. That would be the next layer that I would like to see for some of these IoT devices.

Embedded Intel Solutions: Is everyone on the same page with regard to understanding that solving ransomware attacks and other security problems means adopting a long-term strategy?

Kelsey, Intel Security Group: I am not sure that they are. And this is a cultural problem that we have from an industry perspective and even with respect to human nature. We tend to put function and availability way ahead of confidentiality and the security components that go with that. Organizations should take a really hard look from the bad guy’s perspective—whatever it is they manufacture—and say, “What are the worst things that could happen in this scenario, and what would I ultimately do to provide capability so that I can stop them?

That long term pervasive view is not an easy thing to do. Yes, we have a consortium of car manufacturer and security protocols now that we have started to put together on the backs of various hacks of cars that have happened. Yet this is an example, despite the consortium’s existence, that it takes a longer term of runway to get the devices themselves to, first, interoperate with each other in an overall system and second, have the security mechanisms baked in. You want those two things to happen so that you can protect those components from the onset rather than having an incident and having to do it after the fact. It’s extremely difficult to do it after the fact.

Embedded Intel Solutions: A reactive mode is not want you want.

Kelsey, Intel Security Group: Especially in this area where you are dealing with things that touch so many people. And in a lot of cases, if you’ve got things embedded into a physical, hardware-based, functionality component, then the ability to change, modify, update and/or fix that becomes time consuming and extremely expensive.

Embedded Intel Solutions: Are there past IT security practices the industry should not abandon?

Kelsey, Intel Security Group: This gets down to the everchanging world of IT, and you are correct, there are practices that have been in place for quite some time and they still are very efficient and very effective. When you have the capability of putting a security agent on an actual device, and that agent has the capability of analyzing everything coming in and out of it and making decisions in real time on the device itself, that practice itself is extremely good and extremely efficient. We have gotten really good as an industry in how to deal with that.

The difficulty and the evolution is that the IoT world doesn’t necessarily allow for that capability down at that compute component level. But given Moore’s Law that everything gets twice as powerful with half the size form factor every 18 months to two years, that means that even the devices that are the smallest in size and nature will have more power and capability simply due to the sheer scale.

Sizes will get smaller and smaller. That will allow us—when we can—to put more capability down at the device level. And until that happens, we must do what we can to provide that capability outside the devices themselves. Until we can fully get there, we should take advantage of any opportunities to put security on the device as they occur.

Share and Enjoy:
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
  • TwitThis