IoT Security Testing – Identifying the Scope

IoT (Internet of Things); Where it stands now?

A couple of years back only a handful of people who were involved in the subject knew what IoT is all about. IoT or Internet of Things you should know by now. It’s revolutionized the way we interact with the day-to-day devices and of course technology is very common and IoT will be the next big thing in the coming years. If you want to ensure that, simply google the IoT predictions. Here I am not going to talk about what IoT all about.

There are thousands if not maybe millions of articles on the same subject on the Internet. So in case if you are sitting in the IT industry for several years by now, I hope that you might get crossed with IoT at some point in your career by now. Or if you are a newbie who just entered the arena, my advice is that it’s worth paying some attention to the subject.

Security of an IoT device

Let me dig into the subject now. Day by day, second by second every application and every device connected to the internet is becoming more vulnerable to hackers. The reason is it’s a constant battle where hackers are trying to steal valuable information and people who developed them releasing patches to close the holes in their systems. Why? Ultimately it’s all about money and business. There will be a time where cybersecurity knowledge for a local police officer is mandatory. When it comes to IoT devices, this will be far more critical as they are all about your private data or devices where you get services for your own needs. This leads developers/testers to have a serious thought on the security (physical, firmware and software) of the device.

There are considerable differences when ensuring the security of web/mobile applications to IoT devices. Here onwards, I’ll talk about the areas where you should concentrate on when identifying the scope for an IoT security testing initiative. If you are someone who is engaged in an IoT project and who is also playing the role of developer, QA or just an enthusiast about the subject, the content below will be a valuable piece for your arsenal on the cybersecurity domain.

  • Process matters

    The basics should exist where you will start with scope identification. Then you should start with the threat modeling and map the attack surface. With this, you will be able to see the bigger picture. And you will be able to easily identify the rest what describes below.
  • Hardware (Physical) security

    This will be something new for you in case you only dealt with the application security so far. When you are ensuring the security of the hardware, there are several aspects that you should concentrate on.
    1. Does the device have places that are exposed to human interaction?

      For example, If there is a display (front-end) that exists and applications are usable then we are mostly talking about android (mobile) application security testing. If there is no real estate to display something or having a display just for informational purposes, then you completely out of that headache.
    2. Does the device contain any physical ports?

      Here you need to make sure that if the device having physical ports what are they used for and for what purpose they used. You need to make sure that unnecessary physical ports do not exist. If there are USB ports, then you need to make sure the accessibility of the device by using those. USB debugging should be false unless a hacker will be able to get the root access and do whatever he wishes.
    3. How does the device get access to the internet? Is that through Ethernet or WiFi?

      You need to find out whether a device can connect to the internet via both Ethernet and WiFi or only using a single medium. Based on that your testing methods will get change.
    4. What are the other connectivity methods?

      And at last, if the device connects to Bluetooth, Zigbee or another wireless communication medium, then you need to make sure required security measures are addressed when implementing them. Also, evaluate whether the device trusted the data before accepting them. When it comes to physical security, we have to think about how the device is intended to be accessed from outside. Then close all the access points other than the intended channel. Also if the device store any passwords or any other sensitive data, it is required to make sure that the hardware exists will not expose those data to an outsider (tamper mechanisms).

      If you are interested in this particular subject, it’s better to get more familiar with secure microcontrollers, secure key storage, encryption for physical data channels (pin pad cables, inter IC communication links) and tamper switches. And last, the hardware security standards. It’s worth getting to know the kind of standards your hardware following (Ex- MISRA C). Once you make sure of the above aspects in terms of the coverage on hardware security, you are pretty much safe.

  • Firmware security

    This is the most important piece of your IoT device. This will control all that matters from sensors to the operating system. So having a look at installed firmware on your device is mandatory and if you missed it then you probably missing the big fish of your IoT security testing initiative. There are three major areas in firmware security.
    1. Invest more time on debugging interfaces (USB/Serial/JTAG/SWI)
    2. Protect your bootloader
    3. Implement continuous monitoring on both devices and firmware sides. In addition to the above, please be aware of the firmware level attacks. Below are the possible areas you should consider,
  • Vulnerabilities in third-party components and libraries.

    When developing the firmware there are many third-party libraries and components developers use. So not only scanning via an automated tool but getting a list of all of them and manually validating is critical.
  • Injection attacks where a hacker can alter the firmware logic.

    Then the injection attacks, this is a broader subject. What you need to ensure is if the IoT device can directly interact with the user interface and user can input data via a provided application or even when interacting with the operating system you need to make sure all the fields are properly validated so the user cannot perform injection attacks. Based on the technology the method of injection attacks getting different. If you deal with an application then it can be SQL or NoSQL attacks.

    If you dealing with the OS it can be command injections where you can alter the firmware logic so that you disrupt the normal functions of the device. So it’s very important that making sure your IoT device having a very good defense (on-boot/periodic firmware integrity check) on these types of attacks.
  • Sensitive information at rest and transit

    When talking about sensitive data or PII (Personally Identifiable Information) whether they exist or not in your IoT device will depend on which purpose they intended to be used. It can be even inside your body which monitors your health condition or operating at home or operating publically. What you need to worry about is making sure what kind of data passing through and stores in your device. Can they be classified as sensitive information? If yes, you need to make sure two things. How they transit within the device or to the outside and how they stored.

    When data in transit especially from the backend server to the IoT device and vice versa or when passing the data to some other third-party peripherals it should be secured. Make sure the channel was secured. And make sure they use not only TLS is enough but also the version. Anything below TLS version 1.2 considered not recommended by the industry now. When storing data you should verify PII data stored in plaintext or ciphertext (result on encryption performed on the plain text).
  • DoS attacks

    Another important aspect that you should look at is the DoS (Denial of Service) attacks targeting the firmware. With this hacker can crash the system by utilizing all the available memory. In such a situation please make sure proper mechanisms are enforced concerning the security of the firmware.
  • Key management on client-side

    Another important point when it comes to firmware security is the key management of your IoT device. As you know when a device service or an application communicating with its backend server it uses a secret key to establish the connection. So, in this case, it could be a service running on the firmware. So please make sure where the key is stored on the device and how it stored. Was that the same key used all the time or any key rotation mechanism is implemented. This is very important since a hacker can steal the secret key and do whatever he wants after that.
  • Open ports and services (To the network)

    Finally, you should be aware of what are the open ports and services to the network. Any unnecessary ports should be closed. For example, if the device allows port 23, someone can get into the device via Telnet and take control of it unless proper security mechanisms are not enforced.
  • Software security

    If your IoT device dealing with some applications on top of the firmware then this section matters. Some devices may not have any software which is directly running with the firmware but some may have software that will interact with the firmware and the device (This will depend on the service your IoT device provides). If it uses any software, that means mostly we talking about android applications. You should primarily look on below,

    1. Vulnerabilities exist in the APK
    2. Data in transit and at rest
    3. Injection attacks via input fields
    4. Authentication and authorization mechanisms.

    Here I would not be going to describe each in detail as most covered in the previous sections. But here the applicability is about the software applications. So that you should separately test each area.


In conclusion, before you start everything as I mentioned in the beginning, planning matters where you will perform a deep dive into the overall architecture and then to the threat model. By doing that you will identify where your device stands in terms of the security and how well you should enforce the corresponding security mechanisms. If you consider the areas that I highlighted above when identifying the scope in your IoT security testing, you have a good start to a secure IoT device.

If you have time for preparation, It’s better to study common IoT infrastructures and components first to get some understanding of individual components. Then it will also help to design and study testing procedures relevant to them.

So fasten your seatbelt and start securing your IoT device if already not. You will save lots of money for your business and maybe you will be the one who saves the business ultimately. And besides, I would like to write down that if you are to become a security test professional and you were succeeded in performing your IoT security testing work, please be aware that you enlightened your security testing journey with an area that the future represents…

Chandima Athapattu

Chandima Athapattu is a Lead QA Engineer at Zone24x7.

How you would test a microservices architecture?

First of all, did you ever thought of this topic as an employee who ensuring the quality of the product and worrying to release your product almost bug-free to UAT? Yes, I am talking about testers who think upside down when it comes to test planning in a new testing engagement.

“What is the architecture I am looking at?”
“It’s a microservices architecture… “
“So what it makes sense to me as a tester? Does that matter?”

If you came across with aforementioned answer you should read this else just don’t. But you might get crossed soon.

The identification of microservice architecture is clear. But testing is complex than you think. Testing a microservice architecture is still new for many testers in the industry even today. Why? Because even now, new development work starts mostly in a monolithic architecture. I am not an architecture but a professional tester. I’ll explain this the way all testers will understand.

Why are architects selecting microservices architecture?

Monolithic architecture is well known & well spread in the industry. It’s simply the whole code in one piece. There the whole system developed as a single box and deploying to production. It’s independent and interconnected. This is good sometimes excellent for small systems and as a startup. But this era it’s all about web applications and they evolving rapidly. So many of us

testing/tested systems with monolithic architectures. Companies like Amazon, eBay and google all shifted to microservices architecture. When your system expanding, old fashioned monolithic architectures cannot resist the load. Unable to plug

new technologies. Unable to utilize them in your CI/CD programs because even a little change/update to the system, you need to deploy the whole system to the production which is as you know is hectic to do continuously.

What is microservices architecture?

The solution is indeed microservices. What are these? Your system has broken down to different services without keeping everything together on the code level. For example, let’s look at an insurance system where you will identify claims, policy coverage, alerts & notifications, new businesses & renewals into different services. Then if we consider a single service, within that it will develop the way a monolithic architecture works. But the difference is there are connections in between other microservices so designers need to carefully plan that. With this, all the microservices not need to stick to one technology or database. Developers have space to design their services separately even in different technologies. But don’t forget still this is one system. I am not going to explain further as my objective is to showcase the testing side of this whole thing.

What are the testing challenges?

So what are the challenges? Why in terms of testing systems with microservices architecture getting more complex during designing test cases and execution? There are two reasons,

  • Interconnections between microservices.
  • Different technologies each microservice may use.

That’s all. Here, connections between microservices something we always have to deal with in a microservices architecture. Later, the different technologies each microservice will use is something may not always happen. There can be a system built in a microservices architecture that utilizes the same technologies across the application functionalities. So testers need to understand the architecture clearly.

Web services and microservices. Two different things

Now let’s focus on the topic. How you would test a system with such an architecture? Right now some of you who read this may conflict microservices against the web services. Let me clarify the later. Web services tell us how the communication between two devices/applications held over the world wide web (www). There are two architectural styles. Simple object access protocol or SOAP and Representational state transfer or REST. REST API uses advantages of URL exposure like @path(“WeatherService”) while SOAP API uses services interfaces like @WebService.

So now you may understand that the microservices architecture is one thing and web services and API testing is one thing. Connections I am talking about is which built inside the architecture. Communication among the microservices.

How to overcome the challenges in your strategy?

To address the first challenge which I was mentioned earlier (Connections which exists between microservices) performing an integration testing is vital. Here I should highlight that it’s very important and plays a big role in your overall test suite. You should find a way in your test suite to figure out to test the connections. It can be a manual test (front-end) or an API test. Understanding the dependencies is crucial. And in integration testing, I would say API testing is more efficient. Here too you should clarify two things. Microservices and APIs (endpoints).

A particular microservice may have one or more endpoints based on the design. Or maybe there may not any endpoints connected at all. Such a microservice should have a dependency on another microservice and the later should have one or more endpoints. Sometimes there can be a dependency chain I would say. When planning your API testing you should know the microservices tasks and their dependency (if any). This is something you may not face in a monolithic architecture where such design may not exist. When we say ‘Integration Testing’, various people say various terms. But what you need to know is to cover the integration among microservices. We can call this system integration testing as well. Whatever the name says, make sure to achieve the coverage.

The second challenge I mentioned, different technologies each microservice used is something may not always happen. But you should be prepared. You need to understand the complete microservice architecture and their database connections and external communications with other microservices. Knowing one microservice doesn’t mean you understood the architecture. So your API testing and test data preparation may get vary if two microservices in the same system use two different technologies. For example, one microservice may use SQL and others use an open-source database technology. So you need to figure out how you should design and execute these test cases which is vital and will save lots of time during the test execution.

So after all, the E2E (end to end) testing is the most critical testing type when you are testing a system with microservices architecture. This is where you should test the end to end journey. Business scenarios. In your test suite, you need to identify the E2E test cases carefully. And cover majority if not all of the microservices in the system. Why E2E is this important? This is because in a microservices architecture the two challenges I highlighted. You doing system integration to cover the connections. But end-to-end testing is where you cover business flows. While covering business flows, the different technologies involved in each microservice are covered and the external connections (dependent microservices and data stores).

The solution in brief,

The conclusion is that the classic thinking of integration testing is not part of QA is somewhat not applicable here. You have to consider integration testing while doing system testing we called it system integration testing. Then the E2E testing is critical. As highlighted before, the main reason I would say that is because microservices having an external connection. And you need to think about different technologies which involved in architecture as well. There’s a strong possibility that you might deal with multiple technologies.

The test design phase is vital. You need to plan your test suite carefully. And involving QA in architecture discussions during the design phase is crucial. And please make sure to prepare your test environment as same as in production which is very important here as well.

The trend is towards microservices architecture especially when we are talking about web applications. So hope you have taken all that I have mentioned. And keep this architecture in mind because sooner am repeating, you might get crossed if not already…

Chandima Athapattu

Lead QA Engineer