An Architecture of Enhanced Profiling Assurance for IoT Networks

Abstract

Attacks launched from IoT networks can cause significant damage to critical network systems and services. IoT networks may contain a large volume of devices. Protecting these devices from being abused to launch traffic amplification attacks is critical. The manufacturer usage description (MUD) architecture uses pre-defined stateless access control rules to allow or block specific network traffic without stateful communication inspection. This can lead to false negative filtering of malicious traffic, as the MUD architecture does not include the monitoring of communication states to determine which connections to allow through. This study presents a novel solution, the enhanced profiling assurance (EPA) architecture. It incorporates both stateless and stateful communication inspection, a unique approach that enhances the detection effectiveness of the MUD architecture. EPA contains layered intrusion detection and prevention systems to monitor stateful and stateless communication. It adopts three-way decision theory with three outcomes: allow, deny, and uncertain. Packets that are marked as uncertain must be continuously monitored to determine access permission. Our analysis, conducted with two network scenarios, demonstrates the superiority of the EPA over the MUD architecture in detecting malicious activities.

1. Introduction

Protecting IoT networks from traffic amplification attacks is challenging due to a large volume of devices as attacks cause disruption on the networks. A prominent example is the attack on the domain name service provider DYN, conducted by infecting IoT devices with Mirai malware and using them to attack the DYN central server [1,2]. This attack disrupted many services as they were unable to process requests from users [3]. Recently, Cloudflare published a report on traffic amplification attacks for the first quarter of 2024 [4]. The report showed a 32% increase in attacks compared with the previous year.

The Internet Engineering Task Force (IETF) approved the RFC8520 as a standard for protecting IoT networks [5]. It defines the manufacturer usage description (MUD) architecture for protecting IoT devices from being abused as part of traffic amplification attacks. The MUD architecture uses a device behaviour profile provided by manufacturers or related entities, translated into access control list (ACL) rules, to filter out unwanted or malicious traffic.

Despite the promise of the MUD architecture, it still has limitations that should be addressed to improve the effectiveness of malicious activity detection. The MUD architecture uses pre-defined stateless ACL rules to allow specific communications. This can result in a false negative filter, as MUD architecture does not monitor communication states during a session. The MUD architecture only allows or denies network packets based on pre-defined ACL rules. However, uncertain network behaviours could occur in the traffic, requiring continuous analysis before allowing or rejecting them.

1.1. Objective

The existing limitations of the MUD architecture can cause false negative filtering, decreasing the effectiveness of network communication enforcement. This study proposed the enhanced profiling assurance (EPA) architecture to improve the effectiveness of malicious activity detection. This is achieved by incorporating stateless and stateful inspections to monitor communication states. Three-way decision theory has been adopted with allow, deny, and uncommitted permission to further analyse the uncertain network behaviours.

1.2. Scope

The MUD architecture consists of three main aspects: MUD profile format, MUD profile generation and retrieval, and MUD deployment. This study focuses on the following:

• improvement to the effectiveness of malicious activity detection over the current MUD standard;
• IP-based IoT networks;
• MUD deployment in small-scale networks.

This study will not focus on the following aspects:

• mitigation of other than traffic amplification attacks;
• software-defined network (SDN)-based MUD deployments as these are not found in small-scale networks;
• authentication/authenticity of MUD files;
• MUD profile format/MUD profile generation and retrieval;
• non-IP-based networks;
• large-scale IoT networks.

1.3. Research Method

Our study begins by studying the MUD architecture and MUD file data model to understand the operation of network traffic enforcement. This study then continues investigating recent works on MUD deployment and MUD usage for network traffic analysis. The limitations of the MUD architecture and existing works are then identified to detect the research gap. Based on the identified limitations, EPA is proposed to address the limitations found in the MUD architecture and existing works. The EPA is then analysed in various network communication scenarios to determine the effectiveness of malicious activity detection. This study then concludes with a summary discussion of the proposed EPA and outlines future work to implement the EPA.

1.4. Contribution

The security of the IoT network would be at risk of traffic amplification attacks as the current MUD architecture enforcement does not monitor communication states, leading to false negative filtering. This study is significant to IoT network security as it enhances the MUD architecture by improving the effectiveness of malicious activity detection and reducing false negative filtering. Combining stateless and stateful inspection with three-way decision theory is a unique approach to the MUD architecture, which allows further analysis of the communication states to detect malicious activity.

The contributions of this paper can be expressed as follows:

• proposes a new gateway-based MUD architecture that enables stateless and stateful communication inspection to improve the effectiveness of malicious activity detection;
• employs layered intrusion detection and prevention systems (IDPSs) to improve the effectiveness of malicious activity detection;
• introduces the network behaviour analysis (NBA) system with network behaviour knowledge databases to conduct a stateful inspection of the network communication states;
• presents three-way decision theory with allow, deny, and uncommitted to allow continuous monitoring for uncertain network behaviours.

1.5. Paper Structure

The remainder of this paper is structured as follows: Section 2 provides insight into the background of the MUD architecture and data model. Section 3 reviews the existing works on gateway-based MUD architecture and the usage of MUD for traffic to identify the research gap. Section 4 proposes the architectural design of the EPA, workflow, and network behaviour analysis and decision-making. Section 5 evaluates the different scenarios to determine the effectiveness of malicious activity detection. Finally, Section 6 concludes this study and outlines future work.

2. Background

2.1. Manufacturer Usage Description (MUD)

MUD is a standard defined in RFC8520 [5] for protecting IoT devices from being abused by malicious activities. It enforces communication using pre-defined ACL rules translated from the device network behaviour profile to monitor and filter the traffic. Figure 1 shows an overview of the MUD communication enforcement process.

Figure 1. Overview of MUD communication enforcement process.

When the IoT device connects to the MUD-based network for the first time, it sends the request of its behaviour profile to the MUD central core to retrieve it from the hosted file server. The behaviour profile is then translated into ACL rules to allow or block the specific communication.

2.2. MUD Architecture

The MUD architecture describes the interaction between each component to receive the behaviour profile address (MUD URL) and retrieve the behaviour profile (MUD file) for traffic filtering. The diagram of the MUD architecture is shown in Figure 2.

Figure 2. MUD architecture and interaction between each component.

Details of each component can be expressed as follows:

• Thing: the IoT device that transmits the MUD URL for MUD file retrieval.
• Router/Switch: provides the internet connection to the Thing.
• MUD Manager: the central core of MUD architecture. It retrieves and translates the MUD file into ACL rules for communication enforcement.
• MUD File Server: the file server that hosts the MUD file by the manufacturer or related entities.

MUD Manager functions for communication enforcement are as follows:

• extract the MUD URL from the requested device for MUD file retrieval;
• retrieve the MUD file from the hosted MUD file server;
• translate the MUD file into the ACL rules for communication enforcement at the IDPS;
• maintain and update the behaviour profile and network configuration.

Regarding the MUD file retrieval process, the IETF suggested using the HTTPS protocol to retrieve the MUD file securely. The IoT device must transmit the MUD URL to the MUD manager to extract the MUD URL and retrieve the MUD file.

This study describes the operation of the MUD architecture, as illustrated in Figure 3, to provide more details of the MUD enforcement process.

Figure 3. Sequence diagram of the MUD architecture.

The process of network enforcement in the MUD architecture can be expressed as follows:

• In the first connection, the IoT device transmits the MUD URL to the MUD manager for the MUD profile request.
• The MUD manager extracts the MUD URL for MUD file retrieval and then requests the MUD file from the hosted file server.
• MUD file server authenticating certificate to ensure the authenticity of MUD file request.
• The MUD manager retrieves the MUD file and translates it into the ACL rules to enforce at the IDPS.
• Enforcing ACL rules at the IDPS for traffic monitoring.
• The IDPS receives new connections from the IoT device and conducts stateless inspection based on the ACL rules. The IDPS will permit the communication if the behaviour matches the ACL rules and reject it if it does not.

Our study categorises the deployments of MUD managers as the following:

• software define network (SDN)-based MUD deployment;
• gateway-based MUD deployment.

Our study will only focus on gateway-based MUD deployment, as our study intends to propose an alternative approach to MUD deployment for securing small-scale networks.

2.3. MUD Behaviour Profile

RFC8520 proposed using the network management data modelling language Yet Another Next Generation (YANG) [6] for specifying the intended communication behaviour in the MUD file. The YANG module allows the behaviour profile to be translated into the configuration parameters to configure the IDPS for traffic monitoring.

The MUD file contains two main containers, the MUD and ACL containers. The MUD container is used for MUD file validation, which includes the information related to the MUD file and the access list names. The ACL container contains the intended network behaviours for communication enforcement at the IDPS. Details of the device behaviour information in the ACL containers are as follows:

• Name: Name of the ACL and access control entry (ACE);
• Type: Connection type, either IPv4 or IPv6;
• Protocol: Protocol number defined by the Internet Assigned Numbers Authority (IANA) [7];
• Destination (dst): The address of the destination host to which it is to be connected; Port: Port number usage of each connectivity. Depending on the manufacturer, this can be a well-known port assigned by IANA [8] or a custom port;
• Direction-initiated: Description of connection initiation direction for TCP-based communication. It can be “from-device” or “to-device”;
• Forwarding: Denotes that it will either allow or deny this communication behaviour.

The example of behaviour information in the ACL container of the MUD file is shown in Figure 4.

Figure 4. Code snippet of device communication behaviour.

This code snippet describes the behaviour information of the ACE “from-ipv4-amazon_echo-2”. It specifies that it allows the outbound HTTPS (port 443) to a server (softwareupdates.amazon.com) from the device. If the IDPS detects a matched network packet, it will allow a packet to reach the destination.

3. Related Works

3.1. MUD Impact on IoT Security and Supporters

The introduction of MUD architecture provides a means for reducing risk from malicious activity. Heeb et al. [9] analysed the impact of MUD on IoT security in different attack scenarios. Their analysis showed that the MUD architecture can reduce attacks on the transport layer, especially traffic amplification-based attacks. However, their analysis has yet to point out the limitation of stateless inspection in MUD that can cause false negative filtering.

Due to being a standard for IoT security, MUD has gained support from organisations such as the National Institute of Standards and Technology (NIST). They demonstrated the deployment of MUD-based networks and published guideline documents based on their demonstration for securing home and small business networks [10]. NIST also developed MUD-PD, a companion tool for MUD profile generation, which can be accessed at [11].

Cisco plays a vital role in supporting MUD usage [12]. Cisco has proposed its MUD architecture with the FreeRADIUS-based Identity Services Engine (ISE) for MUD URL authentication [13,14]. Cisco has also developed the Cisco MUD manager as open-source software for its proposed architecture, which can be accessed at [15].

The University of New South Wales (UNSW) IoT Traffic Analytics Research Group also contributed to MUD usage. The team has developed the MUD profile generation tool, MUDGEE [16], which can be accessed at [17]. The team also published the MUD profiles dataset generated from devices in the testbed network [18], which can be accessed at [19].

3.2. Gateway-Based MUD Architecture

The gateway-based MUD network architecture provides an alternative approach for deploying MUD to secure IoT networks. It has the benefit of lower deployment costs when compared to the SDN-based network deployment cost, which makes it suitable for small-scale networks such as smart homes.

To achieve this, the osMUD [20] has been developed for the OpenWRT-based router [21] with the customised version of Dnsmasq [22] for DNS and DHCP services. It was developed for deployment on a network gateway. Currently, the osMUD only supports stateless communication inspection without considering communication states.

Andalibi et al. [23] proposed deploying the MUD manager in fog computing. Two components, the Fog MUD-Manager and peak request rate, have been introduced. The Fog MUD-Manager retrieves the MUD file and enforces at the IDPS to filter communication from local networks. The peak request rate is the parameter used to limit the maximum communication rate with the Fog MUD-Manager. This research only focuses on stateless inspection without considering communication state inspection.

Corno and Manella [24] extended the gateway-based MUD architecture to enhance smart home security by proposing a plug-in for open-source home automation, Home Assistant [25]. The plug-in allows developers to create network behaviour policies for automatic MUD profile generation at local networks. This could benefit legacy devices that cannot transmit the MUD URL or end-of-life devices. However, their research only concerns MUD profile generation and relies on stateless inspection without considering communication state monitoring.

Feraudo et al. [26] introduced the traffic amplification attack mitigation system using MUD and extended the Berkeley packet filter (eBPF)-based traffic filtering. Their research proposed rate limit extension, packet rate, and byte rate to define the communication rate threshold in the MUD profile. Additionally, they implemented the eBPF-based packet filtering as a backend service for traffic filtering. This research only uses a stateless communication inspection without monitoring communication states.

Sajjad et al. [27] proposed enhancing the MUD architecture for vulnerability detection in home routers and connected devices by adopting the OWASP firmware security testing methodology [28]. The vulnerability information is shared with stakeholders via blockchain smart contracts to notify security patching if detected. The vulnerability information also calculates the overall risk for MUD profile retrieval authorisation. Their proposal only focuses on vulnerability detection rather than stateful communication inspection for monitoring communication states.

Feraudo et al. [29] proposed Colearn, the architecture that implemented the osMUD and Federated Learning (FL) framework, PySyft [30], to protect MQTT-based IoT networks. The MUD manager fetches the MUD file from the local User Policies Server (UPS), which is included by network administrators, to assist the FL coordinator in excluding unauthorised devices. Their research focuses on the device connection authorisation and does not concern the stateful communication inspection to monitor communication states.

Datta et al. [31] proposed iDAM, the two-level defence MUD architecture for mitigating volumetric-based attacks. The first level is at the iDAM gateway, which permits MUD-compliant traffic and detects attacks using federated learning-based machine learning. The iDAM manager acts as a second level of protection to enforce and detect anomalies in gateways while maintaining and aggregating the anomaly detection model. This research has not considered stateful traffic inspection for continuously monitoring communication states, which could lead to false negative filtering.

Nisa et al. [32] integrated the blockchain into a gateway-based MUD network for intelligence sensor protection in smart city networks. Their architecture conducts penetration testing to detect vulnerabilities and share information with other gateways via blockchain. Their research concerns vulnerability detection without considering network behaviour analysis.

Afek et al. [33] introduced MUDirect, the MUD architecture for peer-to-peer (P2P) IoT networks. MUDirect contains three main components: a tracking application for tracking IP address changes on mobile devices, a MUDirect service for mapping the P2P connection, and a MUD manager for extracting P2P communication information. The MUD profile has been extended to support the definition of a secondary virtual manufacturer (SVM) for managing P2P communication. This research only focuses on MUD deployment for P2P IoT networks without considering stateful inspection for malicious activity detection in the network packets.

A summary of the literature review on gateway-based MUD deployments is shown in Table 1.

Table 1. Summary of the literature review on gateway-based MUD deployments.

Reference	Application	Inspection Techniques	Description
[23]	Unspecified	Stateless	MUD manager deployment on fog computing.
[24]	Smart home	Stateless	Local behaviour policies and MUD profile generation.
[26]	Unspecified	Stateless	Rate limit extension and backend deployment for packet filtering.
[27]	Smart home	-	Firmware testing and vulnerability detection on the gateway.
[29]	-	Stateless	Focus on employing federated learning for authorising device connection.
[31]	Smart home	Stateless	Employing federated learning with two-level defence.
[32]	Smart cities	-	Firmware testing and vulnerability detection on the gateway.
[33]	Smart home	Stateless	Extending MUD profile to support P2P networks.

3.3. Network Traffic Analysis in MUD-Based Networks

Aside from deploying the MUD to protect the IoT networks from malicious activities, it has also been applied for traffic analysis applications. Hadi et al. [34] presented the MUD-based botnet detection and mitigation system for home routers. They have implemented Snort [35] for analysing MUD-rejected traffic to identify the attack source and notify the user via email. This research only focuses on the analysis of MUD-rejected traffic.

Zangrandi et al. [36] developed MUDScope [37] to analyse and detect anomalies in the rejected traffic. The system can identify four types of attacks: Telnet/SSH port scan, OS scan, vulnerability scan, and TCP SYN flood DDoS. The authors also published the produced dataset, which can be accessed at [38]. Their research only focuses on analysing MUD-rejected traffic.

Andalibi et al. [39] presented MUD-Visualizer, the MUD traffic visualisation tool for displaying MUD communication behaviours. The tool receives sets of MUD files, merges sets of ACEs, and removes redundancy information to visualise MUD traffic information. MUD-Visualizer could assist in MUD deployment by graphically displaying the MUD traffic information, but it is not concerned with traffic inspection for malicious activity detection. The tool can be accessed at [40].

Bremler-Barr et al. [41] proposed MUDIS, a tool for inspecting the similarity of two MUD files and merging them into a single MUD file. The tool will detect the similarity of network behaviours in two MUD files. Then, the remaining unmatched behaviour profiles are clustered into two groups before being merged into a new MUD file. The authors have implemented MUDIS in [42] to demonstrate the impact of location on MUD profile generation. Their research does not focus on malicious activity detection.

A summary of the literature review on traffic analysis in MUD-based networks is shown in Table 2.

Table 2. Summary of the literature review on traffic analysis in MUD-based networks.

Reference	Application Usage	Description
[34]	Smart home protection	MUD-rejected traffic analysis for attack source detection and notification.
[36]	Attack type identification	MUD-rejected traffic analysis to identify attack type.
[39]	Visualising MUD traffic	Development of MUD traffic visualiser tool.
[41]	Behaviour profile inspection and merging	Development of MUD behaviour profile analysis and profile merging tool, MUDIS.
[42]	Impact of location on MUD profile generation demonstration	Implemented MUDIS from [41] to demonstrate the impact of location on MUD profile generation.

3.4. Three-Way Decision Theory for Intrusion Detection

As the attack patterns have evolved, they have become more sophisticated and challenging to distinguish. Some network behaviours might require further investigation to determine the actual type of behaviour. The implementation of three-way decision theory [43,44,45,46] has gained interest as it can support allowing, denying, and uncommitted decisions to further analyse uncertain network behaviours before making a decision.

Shen [47] and Du et al. [48] introduced the usage of a deep belief network (DBN) with three-way decision theory for intrusion detection. DBN has been adopted to extract features from pre-processed data for data classification using three-way decision theory to detect the attack. In case of an uncommitted decision, the authors proposed using a K-nearest neighbour (KNN) to reclassify until no data remains. Shen [47] experimented with the switch flow tables and control domain bandwidth attack detection on SDN. Du et al. [48], on the other hand, evaluated with KDD Cup 99 and NSL-KDD datasets. Their research did not focus on the real-time monitoring of IoT networks.

Zhang et al. [49] and Geng et al. [50] proposed the autoencoder and three-way decision approach for intrusion detection. The character data were pre-processed before being denoised by an autoencoder to construct the multi-granular feature structure. The difference is that Zhang et al. [49] applied using three-way decision while Geng et al. [50] implemented with sequential three-way decision. Both research studies conducted an evaluation with the NSL-KDD dataset but it is yet to be implemented with real-time IoT network monitoring.

Zhang et al. [51] presented the three-branch random forest model for intrusion detection. Each attribute from the training dataset was extracted to calculate the attribute importance before being divided into three domains by three-way decision theory. Then, the model will randomly select the attributes from each domain to train the decision tree to form the random forest for intrusion detection. The proposed model was evaluated with the NSL-KDD dataset. This research is not concerned with real-time IoT communication monitoring.

A summary of the literature review on three-way decision theory for intrusion detection is shown in Table 3.

Table 3. Summary of the literature review on three-way decision theory for intrusion detection.

Reference	Techniques	Evaluation	Description
[47]	DBN, Three-way decision, and KNN	Real SDN traffic	Integrated three-way decision with DBN for intrusion detection in SDN.
[48]	DBN, Three-way decision, and KNN	KDD Cup 99 and NSL-KDD	Integrated three-way decision with DBN for intrusion detection.
[49]	Autoencoder and Three-way decision	NSL-KDD	Using autoencoder for denoising before classification for intrusion detection.
[50]	Autoencoder and Sequential three-way decision	NSL-KDD	Using autoencoder to extract multi-granularity with sequential three-way decision.
[51]	Three-way decision and random forest	NSL-KDD	Using three-way decision to divide attributes for random forest forming.

To identify the research gaps in prior studies of MUD architecture and MUD-based traffic analysis, a summary of MUD architecture and MUD-based traffic analysis is listed as follows:

Heeb et al. [9] discussed the impact of MUD on IoT security by describing its benefits in various threat scenarios. However, they have yet to discuss the limitation of stateless communication in the MUD architecture.

Multiple organisations [10,11,12,13,15,16,18] have shown support for MUD usage. NIST [10,11] only focuses on the demonstration of MUD deployment. Cisco [12,13,15] proposed its MUD architecture but still relies on stateless communication inspection. UNSW [16,18] only focuses on the MUD profile generation.

osMUD [20] provides an alternative approach to deploying MUD in a network gateway for small-scale IoT networks. However, the operation is based on standard MUD architecture, which only conducts stateless communication inspection for traffic filtering.

Numerous studies [23,26] have extended the MUD profile to support the communication rate limit but do not consider the network behaviour analysis for malicious activity detection.

Corno and Manella [24] proposed a plug-in to create intended behaviour profiles for local MUD file generation. Therefore, stateful inspection and malicious activity detection are not the focus of their study.

Various studies [27,32] have only emphasised vulnerability detection in network gateways without considering malicious activity detection in network traffic.

Two studies [29,31] have employed federated learning for malicious activity detection in MUD-based networks. Feraudo et al. [29] only focused on device connection authorisation. Datta et al. [31] employed two-level defences in their architecture but did not support uncommitted decisions to allow ongoing monitoring of uncertain network behaviours.

Afek et al. [33] focused on extending the MUD capability to support peer-to-peer communication in IoT networks. Therefore, their study is specific to peer-to-peer networks.

The research works in [34,36] only focused on analysing MUD-rejected traffic. Hadi et al. [34] analysed MUD-rejected traffic for attack source detection. Zangrandi et al. [36] inspected rejected traffic for attack-type identification.

Andalibi et al. [39] focused on proposing a tool for visualising MUD traffic without considering malicious activity detection.

Bremler-Barr et al. [41,42] emphasised merging two MUD files into one generalised MUD file and discussed the impact of location on MUD file generation.

Different studies [47,48] have implemented DBN for feature extraction to be used in three-way decision theory with different applications. Shen [47] focused on two DDoS attack prevention on SDN and Du et al. [48] evaluated using two datasets. They did not focus on monitoring the IoT network traffic in real-time.

Several studies [49,50] have employed an autoencoder for feature extraction to form the multi-granularity for three-way decisions. They were not concerned with real-time IoT network monitoring.

Zhang et al. [51] employed three-way decision theory for grouping attributes based on the attribute importance calculation for generating a decision tree to form a random forest. This research did not focus on the implementation of real-time IoT network monitoring.

3.5. Limitations of the MUD Architecture

Our study identified the limitations of the MUD architecture and existing works on MUD architecture, which can be expressed as follows:

• The MUD architecture only conducts stateless traffic inspections without monitoring communication states. This could cause false negative filtering, as malicious activities might pass through the MUD enforcement.
• The MUD architecture does not support uncommitted decisions for uncertain network behaviours, which requires continuous analysis.

The MUD architecture only supports stateless inspection to allow or deny network traffic based on pre-defined ACL rules from the MUD file. This can cause false negative filtering as MUD does not monitor communication states to identify malicious activity. Moreover, uncertain network behaviours could occur in the traffic, which requires continuous monitoring to determine access permission. The MUD architecture only supports binary decisions with allow or deny, which is inadequate for supporting the uncommitted decision for ongoing monitoring of uncertain behaviours.

The identified limitations of the MUD architecture and existing works could jeopardise IoT networks as they have yet to consider the stateful inspection for detecting malicious activity. This leads to the intention of the proposal of the new gateway-based MUD architecture, EPA, to improve the effectiveness of malicious activity detection.

4. Proposal of the EPA

This study proposes a new architecture design, EPA, to improve the effectiveness of malicious activity detection. Our EPA considers the following two main aspects to improve the effectiveness of malicious activity detection:

• stateless and stateful communication inspection to detect malicious activity effectively;
• three-way decision-making with allow, deny, and uncommitted to continuously analyse uncertain behaviours.

The overview of the EPA is displayed in Figure 5.

Figure 5. Overview of the EPA.

The EPA employs two layers of an IDPS for stateless and stateful communication monitoring on inbound and outbound traffic to improve the effectiveness of malicious activity detection. The first layer of the IDPS conducts a stateless inspection based on the pre-defined ACL rules from the MUD file. It is placed between the MUD manager and the external connection, focusing on monitoring inbound traffic. The second layer of the IDPS is placed between the local IoT network and the MUD manager to conduct stateful communication inspection on outbound traffic. It receives the communication packets and forwards them to the NBA system for further inspection to detect malicious activity. The behaviour analysis result then updates the ACL rules of both IDPS layers to allow or deny the analysed packet and similar packets.

The reasons for employing two-layer IDPSs are as follows:

• The MUD architecture relies on stateless inspections for packet filtering, which may be insufficient to detect and prevent malicious activities as the attack patterns evolve.
• A two-layer IDPS can separate simple and complex traffic monitoring tasks to reduce the traffic congestion that occurs in the first layer, thus reducing the latency in network inspection.
• A two-layer IDPS design can avoid a single point of failure. If one IDPS is down, another active IDPS can still operate to prevent malicious activity from reaching the destination host.
• The second layer of the IDPS can protect the MUD manager and NBA system by segregating the IoT networks from being directly connected to the MUD manager and NBA system.
• A two-layer IDPS in the EPA is the conceptual design that displays how it can protect against malicious activities. The IDPS can be deployed on a single or separate entity as EPA does not specify the physical setup.

4.1. Components

The EPA incorporates different components to improve the effectiveness of detecting malicious activity in the MUD-based network. The components comprise the MUD manager, NBA system, network behaviour knowledge databases, and two-layer IDPSs. Figure 6 displays the data flow of each component of the EPA.

Figure 6. Internal components of the EPA.

The functionality of each component can be described as follows:

1.

MUD manager

The MUD Manager retrieves the MUD file and translates it into ACL rules to enforce at the first layer of the IDPS. The MUD file is also forwarded to the NBA system to analyse incoming traffic before conducting further analysis.

2.

NBA system

The NBA system conducts stateless and stateful inspections to monitor the communication from local IoT networks. The NBA system should be deployed on edge computing devices.

To analyse the network behaviour, the NBA system includes a packet sniffer to capture the network packet. The network behaviour analysis process uses the behaviour information from the MUD file and network behaviour knowledge database to identify malicious activity in the traffic. The examination process can be expressed as follows:

• the NBA system first conducts stateless inspection using ACL rules from the MUD file for packet filtering;
• the stateful communication inspection is conducted after stateless inspection to monitor communication states for malicious activity detection.

To achieve the objective of stateful communication inspection, the NBA system includes a communication tracking system that tracks and records each communication status.

3.

Network behaviour knowledge databases

Knowledge-based databases are part of the NBA system. They store the network behaviour signatures to conduct a stateful inspection. The network behaviour signatures are stored in three separate databases as follows:

• Abnormal behaviour database

This database stores known abnormal network behaviour signatures that must be rejected, such as ICMP flooding and HTTP flooding patterns.

• Normal behaviour database

This database stores known normal network behaviour signatures to allow communication between the client and server.

• Uncertain behaviour database

This database stores known uncertain behaviour signatures stores for continuous observation.

Our knowledge-based database design supports constantly updating new behaviour signatures, which can be added to existing databases without redesigning the architecture.

4.

First layer of the IDPS

The first layer of the IDPS conducts stateless communication inspection to filter packets. Packet behaviour inspection is based on the ACL rules from the MUD file.

5.

Second layer of the IDPS

The second layer of the IDPS emphasises preventing malicious behaviour from infected devices. It forwards incoming packets to the NBA system to conduct stateless and stateful communication inspections to detect malicious activities and deny them.

4.2. Implementation of the EPA

This section provides an example of a possible implementation of the EPA. In this example, the EPA is constructed from numerous virtual machines (VMs) located in one physical server. This implementation can be set up as per the network topology in Figure 7.

Figure 7. Example of EPA implementation.

The components required for this implementation are as follows:

• one physical server with two network interface cards (NICs) and a Linux-based OS/Hypervisor;
• five Linux-based VMs for the following:
  • MUD manager (OSMUD);
  • packet sniffer (tcpdump)
  • NBA system;
  • first layer of the IDPS (iptables);
  • second layer of the IDPS (iptables).

The EPA does not specify the physical setup. The EPA is flexible and can be integrated into the existing network. For example, it can be deployed into an existing network edge device or appliance.

4.3. EPA Workflow and Decision-Making

4.3.1. Workflow of the EPA

The sequence diagram of the workflow of the EPA is shown in Figure 8.

Figure 8. Workflow of the EPA.

The workflow of the EPA for network behaviour analysis can be expressed as follows:

• the MUD manager retrieves the MUD file, translates it into ACL rules, and then enforces it at the first layer of the IDPS;
• the MUD Manager forwards the MUD file to the NBA system;
• the IoT device sends communication packets through the second layer of the IDPS;
• the second layer of the IDPS forwarded the received packet to be analysed by the NBA system;
• the NBA system compares the received packet against the ACL rules specified in the MUD file;
• if the packet behaviour does not match the ACL rules, it will be rejected;
• if the packet behaviour matches the ACL rules, further analysis will be conducted to detect malicious activity;
• based on the result of the analysis, the NBA system informs the second layer of the IDPS to allow or deny the connection;
• the NBA system informs the first layer of the IDPS to reject similar connection patterns.

4.3.2. Network Behaviour Analysis and Decision-Making Process

The introduction of the network behaviour analysis and decision-making process in EPA is intended to improve the effectiveness of malicious behaviour detection. This extends the decision-making capability of the MUD-based network by allowing an ongoing monitoring process of uncertain network behaviours. The three-way decision-making process of the EPA is shown in Figure 9.

Figure 9. Three-way decision-making process of the EPA.

The flowchart of network behaviour analysis and decision-making is shown in Figure 10.

Figure 10. Flowchart of network behaviour analysis and decision-making process.

The sequence diagram of network behaviour analysis and decision-making process is shown in Figure 11.

Figure 11. Sequence diagram of network behaviour analysis and decision-making process.

The detailed algorithm of the network behaviour analysis and decision-making process can be expressed in Algorithm 1.

Algorithm 1 Network behaviour analysis and decision-making

Require:       MUDretrieval {MUD file retrieval and ACL translation function of MUD manager}       ACLrules {translated ACL rules from MUD file}       packet {captured packet for analysis}       IDPSupdate {function for updating the ACL rules of both IDPSs}       action {action for allowing or denying packet for updating IDPSs}       ongoingmonitor {ongoing behaviour monitoring function}   1: ACLrules ← MUDretrieval()   2: if packet = ACLrules then   3:   if packet = abnormal then   4:     action ← deny   5:     IDPSupdate()   6:     break   7:   else if packet = normal then   8:     action ← allow   9:     IDPSupdate()   10:      break   11:   else if packet = uncertain then   12:     ongoingmonitor()   13:    end if   14: else   15:    return deny   16:    end if

The analysis begins with capturing the network packet and conducting a stateless packet inspection. This process filters the incoming packet by using ACL rules translated from the MUD file. Two possible outcomes of this process are as follows:

• rejection of the unmatched packet;
• further analysis of the packet behaviour to detect malicious activity.

To further analyse the packet behaviour, the NBA system conducts the stateful inspections of packets by investigating and monitoring the communication state to detect malicious activities that the MUD cannot detect. Examples include, but are not limited to, the following:

• the transmission rate is higher than the usual rate;
• the transmission rate does not match the previous rate;
• there is a mismatched protocol and port number usage (for example, traffic arrived at port 80, but it is not the HTTP communication).

The MUD-permitted packet is compared against the abnormal behaviour database to detect malicious activity. If abnormal behaviour is detected, the behaviour analysis system informs the second layer of the IDPS to reject the packet to prevent it from reaching its destination. The analysis result is also updated at the first layer of the IDPS to block similar communication patterns.

Suppose the analysis cannot detect malicious behaviour. The analysis then compares with the normal behaviour database, which will be permitted if it is normal. The first layer of the IDPS has also been updated to allow similar communication patterns to reach the destination.

If the uncertain behaviour is detected, the analysis will call the function for ongoing monitoring for uncertain behaviours to further analyse before allowing or rejecting the packet.

5. Analysis

This section uses two scenarios to demonstrate how the EPA can effectively detect malicious ICMP and HTTP traffic.

5.1. Malicious ICMP Traffic Detection

Suppose an IoT device needs to track the connectivity status of a host vpn.netatmo.net. The MUD file specifies that it allows the IoT device to send ICMP request messages to this host and receive ICMP reply packets from the host, as shown in Figure 12. If the IoT device were compromised and made part of botnets to launch an ICMP flood attack against the host, then the MUD file would fail to block the attack. As the MUD file grants access based on pre-defined access rules, it does not analyse the communication patterns to block this malicious traffic.

Figure 12. Code snippets of a MUD file—allowing ICMP echo-request (a) and echo-reply (b).

The EPA considers the permitted access as an unknown behaviour and conducts behaviour analysis. In the case of an ICMP flood attack, the message volume is usually larger than usual in a short period. The EPA can detect this attack using the knowledge of time difference and communication rate from the abnormal behaviour database. It informs the first layer of the IDPS of the analysis result. Figure 13 shows the process of detecting malicious ICMP behaviour. The ICMP communication behaviour analysis and malicious activity detection process can be described as follows:

Figure 13. Malicious ICMP behaviour detection process in the EPA.

• the IoT device sends ICMP echo-request packets to the destination host through the second layer of the IDPS;
• the second layer of the IDPS forwards the arrived ICMP packets to be analysed by the NBA system;
• the NBA system compares the received ICMP packets against the access control list (ACL) rules specified in the MUD file;
• the ICMP packets match the ACL rule in the MUD file, and then the NBA conducts malicious detection against the abnormal behaviour database, normal database, and uncertain behaviour databases;
• it identifies that this is a malicious ICMP flood attack;
• the NBA system informs the first and second layers of the IDPS to block this malicious ICMP flood traffic.

5.2. Malicious HTTP Traffic Detection

Assume that an IoT device needs to access the data on the web server clients3.google.com via HTTP. The MUD file specifies that it allows the HTTP connection to port 80 of the web server over TCP (identified as protocol 6), as shown in Figure 14. If the IoT device was manipulated as part of botnets to launch an HTTP flood attack against the web server, then the MUD file would not be effective in blocking this HTTP flood attack. As the MUD file grants access based on pre-defined access rules, it does not examine the network traffic for unusual communication patterns to block this malicious traffic.

Figure 14. Code snippet of a MUD file—allowing the HTTP connections to port 80 of the web server.

The EPA considers the permitted access as an unknown behaviour. It conducts network behaviour analysis by monitoring traffic and observing unusual activity and departures from normal network operation patterns. As the HTTP protocol invokes the underlying transport protocol TCP, the communication inspection monitors the three-way handshake process in TCP communication before inspecting the HTTP protocol. The NBA system monitors the traffic and compares it against the abnormal behaviour, followed by the normal behaviour database. It blocks this traffic, as it examines the pattern in the packets that match one of the abnormal behaviour database signatures. The process of malicious HTTP behaviour detection is shown in Figure 15.

Figure 15. Malicious HTTP traffic detection process in the EPA.

The HTTP communication behaviour analysis and malicious activity detection process can be described as follows:

• The IoT device sends HTTP packets through the second layer of the IDPS;
• The second layer of the IDPS forwards the arrived packets to be analysed by the NBA system;
• The NBA system compares the received HTTP packets against the ACL rules specified in the MUD profile;
• The HTTP packets match the ACL rule in the MUD profile. Then, the NBA conducts malicious detection against the abnormal behaviour database, normal database, and uncertain behaviour databases;
• The NBA system inspects the three-way handshake process in TCP communication. Then, it inspects the HTTP request packets to identify that it is a malicious HTTP flood packet;
• The NBA system informs the second layer of the IDPS to reject this HTTP flood communication;
• The second layer of the IDPS forwards the analysis result to the first layer of the IDPS to prevent this malicious communication.

6. Conclusions and Future Work

This work has proposed the EPA to improve the effectiveness of malicious activity detection, focusing on small-scale IP-based IoT network deployment. EPA addresses the limitations of the MUD architecture by incorporating both stateless and stateful inspection to effectively detect malicious activities. EPA adopts a three-way decision theory for continuously analysing uncertain network behaviour by calling the ongoing behaviour monitoring function. We demonstrate the effectiveness of the EPA through the analysis of two communication scenarios, ICMP and HTTP. This shows that our EPA achieves superiority over the MUD architecture in detecting malicious activities in the network traffic. This is because the EPA monitors each communication state to detect and prevent malicious traffic, which differs from the MUD architecture as it relies only on stateless inspection.

The EPA is designed for small-scale networks. The EPA’s ability to scale to larger networks is currently unknown. Incorporating stateless and stateful inspection could increase the computational complexity. We have yet to conduct the complexity analysis as this study primarily focused on the architectural design proposal.

In future work, we will develop a prototype proof of concept and implement three-way decision theory to demonstrate the effectiveness of malicious activity detection and prevention. We will also conduct a complexity analysis to determine the efficiency of the EPA.