OSI’s Model For Security

In just six years, according to Cisco Systems, there will be 50 billion devices interconnected within the IoT universe. IDC puts that number at a whopping 212 billion. Either way, it really doesn’t matter. The fact is that the vast majority will be talking to each other, autonomously, and though the cloud – a nightmare management scenario, no matter how one spins it.

The implications of this are significant and a lot of issues that are coming along with that. Some already exist, some will be new. Others will be complications that arise from the orders of magnitude of increase in these devices. But the one issue that needs to come first on everyone’s agenda is machine security.

There already exists a pretty ubiquitous deployment of machines on Internet, in some fashion or other. Most of these machines, however, have little intelligence and even less, if any, security. Even organizational machines such as RFID readers, copiers and warehouse equipment do little more than talk to the core system, which in most cases is on the premises. In multiple locations, there is more Internet activity, but much of it is secured by technologies such as VPNs or proprietary connection hardware. And the devices themselves use minimal security, such as a passwords, but no other protection.

Machines today
When it comes to security surrounding today’s early IoT machines, security seems to have been mostly ignored. In a 2014 HP study of the most commonly used IoT devices today, 70% of them exhibited some sort of vulnerabilities, including encryption, security, and personal data issues. Within these three categories, some of the specific observations include:

• 60% of the devices that provide user interfaces were vulnerable to a range of issues such as persistent cross-site scripting vulnerabilities and weak credentials.
• 90% of devices collected personal information, and 60% had insecure user interfaces.
• 76% of devices used unencrypted network services, leaving devices vulnerable to man-in-the-middle attacks.
• 80% failed to use of strong passwords. Some of the default passwords were simple, such as 1234 or 0000. And this was the same to protect both the device and to control it via cloud or mobile applications.
• 60% failed to protect firmware downloads with transport encryption or file protection, making it possible for hackers to tamper with device firmware payloads.

Statistics such as these come out, almost daily, from the camps that are genuinely concerned with the overall slow progress around plugging some of these security vulnerabilities – and rightfully so. For example, at the 2014 Black Hat conference researchers were able to hack into a Nest thermostat in just 15 seconds and gain uninterrupted access. They simply replaced its Linux-based firmware with malicious code that could capture network traffic.

At that same conference, Daniel Buentello, a speaker who does Infosec work, pointed out that “connected appliances will become an attractive avenue for cyber criminals, due to the fact that they provide no traditional feedback (monitor) or input (mouse/keyboard). If one were able to compromise an embedded host it would be the perfect vantage point for an M2M attack or a beachhead to launch other attacks.”

In another presentation, Jesus Molina, an independent security consultant, discussed flaws that were found in a hotel’s building automation system, which allowed a hacker to control almost every appliance in the property. So the issues aren’t just with your coffee pot.

The examples above all reference autonomous machine objects on the IoT. The impeding issue is how to derail this efficiently, economically and dependably. While there is no shortage of offerings, there is a good resource that has been the basis of much of what we use in communications protocols today – the OSI model. And, if the IoT is truly just the era of M2M coming of age, and most of the devices within it are autonomous machines, then it should get serious consideration as the base model going forward.

OSI-101
First, and foremost, the OSI stack is just a theoretical reference model. There is no actual OSI software. It has been around since about 1980, and it is based upon recommendations from the ITU-T and the ISO, which developed it to offer an open-standard platform that defines how data communications should take place. It is a series of functions or processes split into seven groups or “layers,” with each layer designed interface the layer above and below it (see Figure 1). It has given us functional protocols such as Ethernet, Wi-Fi, TCP-IP, IPsec and many others since its inception.

The layers serve as installation platforms for emerging or developed standards and protocols. When protocols are developed by organizations such as, IEEE, ANSI, or the ITU-T, for example, they are inserted into the appropriate layer of the model (see Figure 2). What makes this so nice is that it is possible to use applicable protocols within the stack (such as TCP-IP, Wi-Fi, Ethernet, etc.) and apply security to them. The OSI model is supported by the majority of major network and computer vendors, large commercial entities, and governments. This makes it very attractive as the model for locking down the devices that will start to flood the IoT/E, CoT.

However, it will take a lot of cooperation and agreement among a stratification of warring camps to make it work well. Yet, stranger things have happened. With that in mind, let us have a look at what is currently on the radar screen.

Peeling back the layers
One good thing about this stack is that it is broken out into multiple layers, each with specific protocols, which means is has a diverse working surface.

Fig. 1: The 7-layer OSI model. Courtesy technology.blurtit.com.

Fig. 2. Protocols within the layers. (Courtesy Acturus Networks)

Security protocols can be implemented in just about any layer – either generically, or as applications that have their own security protocols for encryption, at the respective layer. For example, HTTPS and SSH operate at Layer 4 while IPsec, which is commonly used in routed networks, is implemented in layer 3. And, Ethernet works at layer 4. But there is a relationship between security protocols and locations layer. The closer it gets to the physical layer, the better the security will be.

The most bulletproof layer for security is the physical layer. However, even there, Denial-of-Service attacks can be carried out. Such attacks are rare in wired networks since they have to have direct access to the medium of transmission. However, wireless is very vulnerable. Security at this layer can be very strong, but can be expensive and complex. This may be warranted for the most critical of IoT devices, but unlikely to find acceptance for the majority of them.

Ethernet networks exist at layer two of the OSI stack and Ethernet is an excellent candidate for IoT device security because it is next to the physical layer. Security here can be relatively strong for the devices. Ethernet networks already have their own encryption protocol as defined in the IEEE standard, 802.1AE so porting to IoT devices should be fairly straightforward. And that seems to be the case because the buzz seems to be pointing toward standardization on Ethernet protocols.

One of the reasons Ethernet has been so well accepted is because it can offer strong encryption. And that has boded well for the Internet’s function so far – information. But as the IoT shifts to a network of devices from a network of information, untrusted devices accessing a network become a paramount concern. A solution is to authenticate the devices themselves and control access and communications protocols, not just encrypt device data.

The mechanics
So how can that be addressed in the Ethernet pool? The answer is the KeySec protocol. It is defined in the 802.1x standards, and enables authentication and authorization in the Ethernet protocol stack. This can be done by using what is called a Radius authentication server to authenticate origin of secured data.

Data integrity and confidentiality in the Ethernet stack is available via the 802.11AE MACsec ICV field and AES encryption. The ICV field gets corrupted if an internet payload package is hacked. AES is the standard 128- or 256-bit encryption standard applied to the data and will be one of the key devices for IoT security.

Finally, the MACsec protocol is much simpler and cheaper to implement than IPsec (which resides in level 3), and is readily deployable in IoT networks. It supports high-speed, wide bandwidth (1 to 100 GHz), and requires little overhead on payload header management.

On the power side it is relatively low and doesn’t require a dedicated secure processor. And it is linearly scalable, offering a much more robust platform when it comes to links and endpoints in hop and end-to-end applications.

Looking ahead
The OSI model provides some interesting opportunities to lock down security in the new order of the internet. Since one of the driving forces, as the IoT evolves, is cost, a mature and flexible standard such as Ethernet offers some attractive economies of scale in large deployments. There are other options in the OSI model but at present, Ethernet is getting the hardest looks.

Currently, the Ethernet stack appears to offer enough robustness and includes protocols that can be adapted to securing objects as well as encrypting data. But it is hard to extrapolate just how all of this will really shake out when there are 200 billion-plus objects all vying for a chunk of the pipeline. Remember, most of them will be autonomous and always online.

Today Ethernet looks like a pretty good option. But as with all things, technology marches on. By the time those billions and billions of autonomous objects really start to show up op on the IoT, perhaps it no longer will be the shining star.