Is there a perfect IoT security architecture outside? I’m pretty sure there isn’t. And I’m not alone in this opinion. Also, the European Union Agency For Network and Information Security (ENISA) did an analysis on this topic and found at least 8 different architecture, you can have a closer look on the publication in my previous article Industry Best Practice for IoT Security (PDF). Are there bad IoT security architectures? I’m pretty sure there are! Sounds quite strange, isn’t it? No! The key in security architectures is, you can easily prove whether something will protect your iot system from a specific attack but you can not prove whether you have foreseen all possible attacks. By the way, it is exactly the same for bug hunting in software.

Therefore there are criteria which can be used to verify a security architecture. Most of them are referencing standard security principles like security by default, defense in the depth or need to know principle.

In the last years, I’ve seen some architectures which were titled as iot security architectures and want share them with you today and explain my pains with such. AND what is the best salt for a sarcastic IT article ... exactly dilbert comics - I love them. Here is the link dilbert.com - prominently on the top of the page to contribute to the great work.

Top 3 iot security architectures from the field?

Talking to a large number of companies who are interested in a partnership, trying to place there products, interested in OEM business, brand labeling or simply I had a chat with, on one of the conferences or exhibitions I always ask what kind of security measures they have implemented in the product.

What I’ve noticed is, there is no one saying “sorry man we didn’t implemented any security measures at all due to [any reason]” or the better case is “sorry man I do not have a clue about this topics, let me involve our expert for the next meeting”. But there are two main parties of the “implementers”. The one who is asking back some question, to make sure to understand the intention of mine, and then just talk about the security measures using the common cybersecurity vocabulary – these guys are mainly engineers or sales with a strong technical background. If they don’t know what is implemented in the product, or there is nothing relevant they just chat about the importance of iot security.

AND there is the great group of the ones who think they rule the world just being there. First they have the best iot security concept on the market, second, they are the first worldwide who was invented iot security and third you are the fool if you ask critical questions. This group shared a lot of great iot security architectures with me in the past and a don’t want to carry them only in my mind.

Disclaimer: There is also a 3rd group I call “I don’t know who shall be interested in my data”, they are quite boring, they have no interesting ideas they can share with me and every statement about importance of security mechanisms is answered with “Who needs the data and if someone will get them, what will he do with it”. I will just ignore them in this article.

Ok, here are my top 3 iot security architectures from the field. Please don’t get it too serious.

3.“Product Security? Yes sure we are using HTTPS” - security architecture

Following scenario on an exhibition, I’m talking with an IoT device manufacturer about his product, mostly technical topics. Connectivity? BLE , Sensors? Temperature, Acceleration! Accuracy, sampling timings, IP class etc.

Me: “How do you see the IoT security topic? How do you protect your devices?”

Manufacturer: “Everything fine, we are using HTTPS!”

Me: “Ok! .. to connect to the cloud, what about other components in the system? Sensors, Gateways?”

Manufacturer: “Yes, the data is encrypted on the way via HTTPS”

Me: “But you store also the data on the sensor and transmit it to the Gateway via BLE, there is also a possibility to log in to the gateway, right? What about the security mechanisms there”

Manufacturer: “Ahh see what you mean. The sensor and gateway are in your environment, therefore well protected. Only the connection is critical and this is protected”

Ok lets make a break here. HTTPS, or better HTTP + SSL/TLS as the underlying technology, is widely used and great to secure IP communication even independent from the communications medium but this is not a universal remedy.

But HTTPS does not provide any protection to the data which is stored on a piece of hardware. It also not securing non-IP communication protocols like the L2CAP for BLE. The same is for the hardware, Debug Ports – unprotected, JTAG interface – unprotected. On such a product a potential attacker will not deal with the hard encryption on HTTPS but will simply chose one of the holes which are much easier e.g. man in the middle for BLE, or try to find the credentials for the cloud application on the gateway or the sensor memory. Here are some tips what is to do to improve such an iot security architecture significantly.

Protect every your endpoints, e.g. encrypt stored data do not focus only on the data which is moving on the web – you can find more tips in my previous article 5 Easy Ways To Better IoT Security Protect non-IP, e.g. BLE, ZigBee, communication properly. Most of the technologies have basic security mechanisms in place use them. If better protection is required, get in touch with experts. Protect integrity of your software sign firmware and software updates Harden you system by closing ethernet ports, debug and flashing ports.

And an additional tip ... be really careful making assumptions about how the customer will use the device, in the most cases it is totally different.

2. “Everything is running on a private network” - security architecture

Place two but definitely my favorite group! The “global” IoT companies who are running their server as if they have only home network to share some pictures with their partner. This party is extremely hard to identify due to the fact, that the real IoT security architecture can be hidden behind fancy words or simply the statement to be confidential if you ask for some details.

One note here, I’m a supporter of the idea that the security architecture shall be designed in the way that a publication will not affect it, exactly the same as for cryptographic functions. No security through obscurity also for security concepts so to say. This is exactly why I rate the security of an IoT product as “bad” or “not available” if a potential partner is hiding it, even under NDA, true to the motto “not tested means doesn’t work” or the analogy here is “not seen means not available”.

Let us come back to our special group. The roots of the group are located somewhere between private home network implementers, small companies running their IT infrastructure by one guy who is the nephew of the CTO and companies which the main field of business is outside the IT.

The good news is, one of the roots is willing to learn and to improve. The companies outside IT, e.g. machine manufacturers, are knowing that they do not have the knowledge by themselves and are often looking for experts who will drive the process on their side. The others are often really convinced about the iot security architecture and are not ready to accept that their work is really in danger and have also the potential to endanger their customers.

What is wrong with the “security” architecture? One thing is it often comes with the assumption that nobody knows about the details (security by obscurity), the other is that only the outer “fences” are secured. Within the fences, there are typically no security measures at all – because it is private and shall not be accessible. So “defense in the depth” is the second principle which is often violated, as well as the principles to use independent defense lines, which is a subpart of defense in the depth principle and also not to trust the infrastructure.

Well, the idea to build the fences around your solution is already a good mindset, let’s see how it can be improved. Here are some tips how to turn such an iot solution into a solid iot security architecture.

Structure and simplify your architecture within the fences, use well known and accepted products Use an independent key management system wherever possible Encrypt databases Secure the interconnections in between your services and application like they were not locally Remove data which is not needed (“Need to know principle”)

How will you benefit from such changes? Well, if you were untouched by security accidents before, you will not see any changes. This is the bad thing on security, you did a great job if no one noticed any changes and nothing is happening. But there is something besides the security improvement, you have now a system architecture which is prepared to be distributed. All components are separated and the communication in between is secured no you do not care whether your service is running in your local castle or on the other server, which gains your performance.

1. “We use known providers” - security architecture

The first place got a very common iot security architecture which I call „We use known providers“ or you can also call it „all of our partners are having crazy certifications I don‘t have a clue about, but they sound very important“. How can you identify them? This is quite easy, here is a step by step guide

Watch out for common platform names like Amazon AWS, Microsoft Azure, IBM Bluemix or other big players on the flyers or the companies stand. Pay attention whether the sales guy is talking about the product or only about the partners' solution. After a long eulogy on the performance and functionality of the platform, ask something like “OK and what is exactly your product doing?” or “What is the contribution of your team to the security of the product?” or even harder “I can use AWS too, why do I need your product?”

YEAAHH, Now the salesmen, who used to be your best friend, is hating you like hell!

The best name for such an approach is “It’s not my responsibility” security concept. OK blaming the others is easy ... what is wrong with it, one can ask. A lot! But firstly the good thing, choosing partners or platforms who/which are common on the market, proved and certified in accordance with international standards is a really good choice. And also using services they offer e.g. for authentication is better then do it your self.

The bad part, a lot of the startups and also bigger companies are thinking it is enough to have somewhere in the product the word “security” or terms of the technical implementation of security to have a secure iot product.

The cloud providers offer you only the basis, the framework, the infrastructure for your solution. Yes they are securing their systems, but their potential attackers are your equals with bad intentions, it is not your customers or someone who wants to hack them. The cloud providers are only responsible for the secure implementation of the modules they offer you not how you run them and definitively not the applications you plan or has built on the top of this infrastructure.

You are responsible for your iot device security both hardware and software, you are also responsible for the security of the communication channels. If the TLS/dTLS connector was provided by the cloud infrastructure, you are responsible for the proper configuration. At least you are responsible to control the company you pay to provide, operate and maintain the security infrastructure.

The great Bruce Schneier once said:

"If you think technology can solve your security problems, then you don’t understand the problems and you don’t understand the technology.”

This is exactly what I as a client expect from your product, you shall understand iot security problems, you shall understand your technologies – all of them in your solution! And you shall provide me a product with a holistic security concept and not a patchwork.

For someone who has at least ½ year experience in the field of iot security, or cybersecurity in general it is extremely easy to identify you as someone who is just using big words or to see that there is really a strive to have a secure product.

(IoT) Security Principles Check

The iot security architectures I’ve introduced to you are ignoring one or more basic (iot) security principles. The one which is ignored very often this is “defense in depth” – principle.

Defense in the depth requires a multilayer security architecture with independent security components. The idea behind is that is coming from the military tactics and shall prevent a full destruction only because one of the security mechanisms was failing – Definition by OWASP. This is not given by any of the 3 iot security architectures from the field.

The next principles which ignored extremely often are the one called “Don’t trust infrastructure”-principle. It is telling you exactly what it is… don’t trust the infrastructure. Don’t trust the cables your packets traveling around and the ISP is responsible for. Don’t trust the highly secure cloud servers you store your data on. Don’t trust the infrastructure the customer will use your product in. My tactics to check whether I rely on infrastructure is often, just ask yourself how easy it is to move your solution to the other provider. If the requirements are purely technical, like there must be a mongoDB + nginx server running, then highly likely that your security architecture does not depend on the infrastructure. More details about the Don’t trust infrastructure - principle.

The last but most important principle pair combines all other principles together. It should be the essence of any and each product which is at one time in its life connected to the internet or any other public network infrastructure. But also if the device is running solely on a private network you should think about device security to not create a weak point, especial if we talk about secure networks. I’m talking about security by design and security by default. Which means that your product is designed already in the way that it is prepared to withstand security attacks or minimize the risk. More details about Security by Design

One topic is also extremely important for me, we are talking about “building” or “implementing” security measures in iot products, but the guys who are implementing the functions are in the most cases not the reason for failing security. Let us not looking for the scapegoat in the implementation team. Security of your iot product is a combination of strong security support from the corporate management, readiness to invest from the product management, proper planning of security tasks during the project development phase and strong security knowledge and security awareness in the development team.

Summary

None of the iot security concepts, we had a look on today, are enough for a serious iot solution to operate in the wild. Some approaches are maybe enough for well-protected environments others are only marketing buzzwords. The common thing all of them have is, they are very easy to discover. Don‘t do the mistake and let your sales and marketing promote great security features if they are not. If you plan to sell a product to a company which takes the iot security topics serious you will simply fail and lose the interest of this company for a very long time. And the worst thing is, you will fail late because the detailed check by a security expert will happen late, in the most times.

Relevant Articles about IoT Security

IoT Security is a recurring topic in my blog if you found the way to this article I will try to ease the way to the previous for you.

Relevant Books

There a also a lot of good books on the market facing IoT Security topics here are some popular examples

Infographic