The State of Embedded Systems Safety

Embedded Systems Safety

In The Internet of Insecure Things we got a glimpse into the source of some of those security issues. Today we benefit from another infographic reproduced courtesy of the Barr Group. This time it is a look at the underlying Software Security that is so important to improving the future and no making it even more vulnerable. So read through the list of areas you might not be paying enough attention to. I know there are a couple we are still working on.

 

The State Of Embedded Systems Safety

The State Of Embedded Systems Safety

Food for thought. Above I reproduced a low resolution version with their permission. You can get a full resolution version by registering at the Barr Group website.

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development, focusing on products that are intended to be Made In AustraliaRay Keefe has developed market leading electronics products in Australia for more than 30 years. This post is Copyright © 2018 Successful Endeavours Pty Ltd.

IoT Security

IoT Security

The Internet of Things, or IoT, is a pivotal component of the future and is driving initiatives from Smart Cities through Ubiquitous Computing and Augmented Reality. Of course the next step up from Smart Cities is a Smarter Planet. But we aren’t at Smart Cities yet.

 

An enabling technology like IoT can also have roadblocks to adoption. The principal ones being addressed now are:

 

  • power consumption
  • cost of goods
  • size
  • security

 

The biggest issue right now is IoT Security. Recent DDoS (Distributed Denial of Service) attacks have used IoT Devices as the attack launchers. They are being selected because many have weaker security than fully fledged computing devices.

 

DDoS or Distributed Denial of Service

DDoS or Distributed Denial of Service

In a recent article on IEEE Spectrum on the Path to IoT Security it is argued that IoT Manufacturers must take responsibility and not leave it up to end users. There is also a role of industry standards however no clear set of standards have yet been agreed. So although 2016 is the Year of IoT, with this being the single biggest category of product shipped, it is still very early days where things like IoT Security and IoT Interoperability are concerned.

 

IoT Security versus Software Security

This is not a new dilemma. Software Security is always important and it becomes increasingly important as Internet Communicating IoT Devices become more widespread. One apparent assumption underlying all this is that an IoT Device must be a fully IP Stack capable platform. That is not necessarily the case. In the video I shared about our Water Metering Remote Telemetry project one thing I didn’t mention is that the data stream is all driven from the IoT Device. There is nothing to log into. You can’t patch it with a Windows, Linux or other OS patch to override its function. It is not capable of being used in a DDoS attack because you can’t get to anything in it that can do that. So it is inherently secure against that form of risk.

 

Internet of Things Cconnectivity

Internet of Things Connectivity

 

However there are other risks. Nick Hunn has an insightful piece on Wireless Security for IoT where he argues that we are declaring security is present while having no evidence of proving it. That article is a little dated but the basic tenets still seem to apply. Just because a manufacturer or industry alliance states they have addressed security, it doesn’t make it automatically true.

 

So IoT Security is Software Security with the added component of protecting the physical hardware.

 

IoT Security in the Future

We still don’t have standards, so for now, individual device manufacturers and alliance members will need to ensure they have adequate security out of the box. The level of security required is determined by the importance of the data, either its security against unauthorised access, or its integrity against falsification. And at the asset level, its proof against either being disabled or used as an attack vector.

 

As an example, I am personally not so concerned if a hacker can find out how much electricity use my smart meter is reporting. Unless they get time of day usage and can correlate with other data sources to work out in advance when we aren’t home so they can rob us. My energy provider probably cares more about this data for all its customers coming into a competitors hands. Or maybe not. But I do care that I don’t get an outrageous bill because they were able to send fake data for my account to a server.

 

And energy grid managers care about usage data and Smart Meter appliance management being used to crash an entire electricity grid!

 

In the case of the Water Metering Remote Telemetry project I care that it remains online and working because otherwise someone will have to travel a long way to fix it. We have a facility in Gilgandra that is 892Km away as the crow flies. It will take a full day to get there and then another to get back again. So I want it to be proof against some hacker disabling its communication ability. Since it has a physical antenna, I do care about that being hard to break. So some of these devices are put above normal reach and everything is inside a secure plastic case including the antenna. And our customer wants to know the reported water usage is correct. This means no missing data, and no incorrect data. They use the data to bill their customers.

 

One simple way to mess up data is a Replay Attack. If you can intercept and copy a data transmission, then you can play back that transmission any time you want to. You don’t even have to understand the content, the encryption, anything. Simply capture a HTTP POST or GET and replay it. Why does this matter? Because if the data transmitted is the volume of water used since the last report, then every time you play it back, you add to someone’s water bill. Or you distort the level of water the system believes is in a tank or reservoir. You can protect against these attacks in a number of ways but you have to consider the need to protect against them first of all.

 

There is a large volume of material on this topic. Here are some additional articles you might find useful for broadening your perspective on this topic:

 

 

I’m sure you won’t find it hard to search out a lot more articles. Just consider this. Once it has an Internet connection, any device can access anywhere in the world. And most firewalls protect against incoming attacks. A corrupted device on the inside can get out any time it wants to.

 

Internet of Things Global Reach

Internet of Things Global Reach

 

And if you want a really interesting view of what this could be like 10 years from now, I recommend reading Rainbow’s End by Vernor Vinge. Enjoy. And this isn’t my first reference to this book because I think it is fairly prescient in its exploration of a most probable future.

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development, focusing on products that are intended to be Made In Australia. Ray Keefe has developed market leading electronics products in Australia for more than 30 years. This post is Copyright © 2016 Successful Endeavours Pty Ltd.

Software Security

Security of Software Systems

This post looks at security of software systems in the embedded realm. We are fortunate to have some good recommendations from IEEE on this topic. The first looks at avoiding Software Security Design Flaws. The summary is outlined below:

 

  1. Earn or give, but never assume, trust. Make sure all data received from an untrusted client are properly validated before processing. When designing systems, be sure to consider the context where code will be executed, where data will go, and where data entering your system come from. Failing to consider these things will expose you to vulnerabilities associated with trusting components that have not earned that trust.
  2. Use an authentication mechanism that cannot be bypassed or tampered with. Such mechanisms are critical to secure designs, but they can be susceptible to various forms of tampering and may be bypassed if not designed correctly. The centre recommends a single authentication mechanism that leverages one or more factors for each application’s requirements; that it serves as a “choke point” to avoid potential bypass; and that authentication credentials have limited lifetimes, be unforgettable, and be stored so that if the stored form is stolen, it cannot easily be used by the thief to pose as a legitimate user.
  3. Authorise after you authenticate. Authorisation should be conducted as an explicit check, even after an initial authentication has been completed. Authorisation depends not only on the privileges associated with an authenticated user but also on the context of the request.
  4. Strictly separate data and control instructions, and never process control instructions received from untrusted sources. Lack of strict separation between data and code often leads to untrusted data controlling the execution flow of a software system.
  5. Define an approach that ensures that all data are explicitly validated. Software systems and components commonly make assumptions about data they operate on. It is important to explicitly ensure that such assumptions hold. Vulnerabilities frequently arise from implicit assumptions about data, which can be exploited if an attacker can subvert and invalidate these assumptions.
  6. Use cryptography correctly. Cryptography is one of the most important tools for building secure systems. With it one can ensure the confidentiality of data, protect data from unauthorised modification, and authenticate the source of data.
  7. Identify the sensitive data and how they should be handled. One of the first tasks for systems designers is to identify sensitive data and determine how to protect them. Many deployed systems over the years have failed to protect data appropriately. This can happen when designers fail to identify data as sensitive, or when designers do not identify all the ways in which data could be manipulated or exposed.
  8.  Always consider the users. The security stance of a software system is inextricably linked to what its users do with it. It is therefore very important that all security-related mechanisms are designed to make it easy to deploy, configure, use, and update the system securely. Remember, security is not a feature that can simply be added to a software system but rather a property emerging from how the system is built and operated.
  9. Understand how integrating external components changes your attack surface. It is unlikely that you will develop a new system without using external pieces of software. In fact, when adding functionality to an existing system, developers often make use of existing components.
  10. Be flexible when considering future changes to objects and actors. Software security must be designed for change; it should not be fragile, brittle, and static. During the design and development processes, the goal is to meet a set of functional and security requirements. However, software, the environments running software, and threats and attacks against software all change over time. Even when security is considered during design, or the framework being used is built correctly to permit run-time changes in a controlled and secure manner, designers still must consider the security implications of future changes.

 

Wearable Device Security

The second input is specifically looking at how to protect very small computing systems such as wearables from cyber attacks. You can read the complete report at Protect Wearable Devices Against Cyber Attacks. The two primary points made are:

 

  • Authentication matters – really think about how you will authenticate users
  • Ultimately code decides what happens. So mange the code base well

 

We are working constantly in the IoT space and so managing security and access is a big issues for these projects. If security isn’t front and centre, then field deployed devices are all in trouble.

 

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years. This post is Copyright © 2016 Successful Endeavours Pty Ltd