Clear as MUD: Generating, Validating and Applying IoT Behaviorial Profiles (Technical Report)
Ayyoob Hamza, Dinesha Ranathunga, H. Habibi Gharakheili, Matthew Roughan, Vijay Sivaraman
CClear as MUD: Generating, Validatingand Applying IoT Behaviorial Profiles(Technical Report)
Ayyoob Hamza ∗ , Dinesha Ranathunga † , H. Habibi Gharakheili ∗ Matthew Roughan ∗ and Vijay Sivaraman ∗∗ University of New South Wales, Australia † ACEMS, University of Adelaide, AustraliaEmail: [email protected], { h.habibi, vijay } @unsw.edu.au, { dinesha.ranathunga, matthew.roughan } @adelaide.edu.au Abstract —IoT devices are increasingly being implicated incyber-attacks, driving community concern about the risks theypose to critical infrastructure, corporations, and citizens. In orderto reduce this risk, the IETF is pushing IoT vendors to developformal specifications of the intended purpose of their IoT devices,in the form of a Manufacturer Usage Description (MUD), sothat their network behavior in any operating environment canbe locked down and verified rigorously.This paper aims to assist IoT manufacturers in developingand verifying MUD profiles, while also helping adopters of thesedevices to ensure they are compatible with their organizationalpolicies. Our first contribution is to develop a tool that takes thetraffic trace of an arbitrary IoT device as input and automaticallygenerates a MUD profile for it. We contribute our tool as opensource, apply it to 28 consumer IoT devices, and highlightinsights and challenges encountered in the process. Our secondcontribution is to apply a formal semantic framework thatnot only validates a given MUD profile for consistency, butalso checks its compatibility with a given organizational policy.Finally, we apply our framework to representative organizationsand selected devices, to demonstrate how MUD can reduce theeffort needed for IoT acceptance testing.
I. I
NTRODUCTION
Many online IoT devices can be found on search enginessuch as Shodan [13], and if they have any vulnerability,it can then be exploited at scale, for example, to launchDDoS attacks. For instance, Dyn, a major DNS, was attackedby means of a DDoS attack originated from a large IoTbotnet composed of thousands of compromised IP-cameras[9]. IoT devices, exposing TCP/UDP ports to arbitrary remoteendpoints, are used by attackers to reflect/amplify attacks orto infiltrate otherwise secure networks.This has prompted standards bodies to provide guidelinesfor the Internet community to build secure IoT devices andservices [15]–[17]. In addition, the US Federal Communica-tions Commission (FCC) has stated the need for additionalregulation of IoT systems [6]. There is also a practical proposalcalled Manufacturer Usage Description (MUD) which is beingreviewed by the IETF. This proposal requires manufacturersof IoTs to publish a behavioral profile of their device. Manu-facturers have the most insight into what resources the deviceswill need once they are installed in a network; for example,an IP camera should only use DNS and DHCP on the localnetwork, and communicate to NTP server and its own cloud-based controller, but nothing else. These requirements vary across IoTs from different manufacturers. Knowing each one’srequirements would allow a tight set of Access Control Lists(ACLs) to be imposed.Manufacturers should be best-suited to author the networkprofiles which will be required by their devices. Therefore,the IETF MUD proposal provides a light-weight model ofachieving very effective baseline security for IoT devicesby simply allowing a network to automatically configurethe required network access for IoT devices so that theycan perform their intended functions without granting themunrestricted network privileges. However, what do we do ifa manufacturer incorrectly specifies its MUD or the MUDprofile conflicts with the security policy of our network?The MUD approach differs from existing cyber-security ap-proaches because it is an open and standards-based approach,uses the subject matter expertise of device manufacturers,and importantly is scalable to minimize the effort of securingIoT endpoints. But, manufacturers need help to generate andverify their MUD profiles, and network operators to verifythe compatibility of MUD profiles with their organizationalpolicies.MUD is a new and emerging paradigm, and there is littlecollective wisdom today on how manufacturers should developbehavioral profiles of their IoT devices, or how organizationsshould use these profiles to secure their network. This paperis our attempt to address both these shortcomings.Our specific contributions are as follows: We first developa tool that takes the packet trace of an IoT device as input andautomatically generates a MUD profile for it. We contributeour tool as open source, apply it to 28 consumer IoT devices,and highlight insights and challenges encountered in the pro-cess. We then apply a formal semantic framework that not onlyvalidates a given MUD profile for consistency, but also checksits compatibility with a given organizational policy. Finally,we apply our framework to representative organizations andselected devices, to demonstrate how MUD can reduce theeffort needed for IoT acceptance testing.II. B
ACKGROUND AND R ELATED W ORKS
Security of IoT devices has not kept up with the rapidpace of innovation, creating substantial safety and economicrisks for the Internet [14]. Today, many IoT products do1 a r X i v : . [ c s . CR ] A p r ig. 1: A metagraph consisting of six variables, five sets andthree edges. not incorporate even basic security measures [12]. As IoTbotnets grow and become mature, attackers are using themto launch more advanced DDoS attacks [3]; devices such asbaby monitors, refrigerators and smart plugs have been hackedand controlled remotely [26]; there are many cameras that canbe accessed publicly [1], [31] since network operators often donot impose access control policies to these IoT devices [28].While it may seem impossible to identify all potential formsof adversary or to stop all anticipated threats, we should atleast be able to enhance the penetration resistance of IoTs andmake them less vulnerable [16]. It has been shown that IoTsoften employ a limited set of flow rules to few remote/Internet-based endpoints in a recognizable pattern [25]. So it shouldbe possible to discover and prevent unintended activity at thenetwork level. But, only if we knew what behavior is intended.The Internet draft for MUD specification [11] promotesthe device manufacturer to clearly define the communicationpattern of a device in the form of access control rules. Thisallows network monitoring tools to secure the device basedon the principle that if an observed behavior of the deviceis not in the profile, then that communication is considereda threat. By translating access control rules to network ruleswe can restrict local/remote communication to restricted flowsand endpoints. This helps safeguard the device.An operational critical infrastructure or enterprise network,should have a local security policy. The IETF MUD specifica-tion proposes plug and play of IoT devices in a network, butthis convenience brings with it serious security implications.For instance, a MUD controller’s attempt to dynamicallyenable a MUD policy in a network for a freshly connectedIoT device can result in the breach of security policy or bestpractices. In this paper we propose an extension that can beused along with the MUD controller to check compliance ofa MUD profile with an organizational policy. We show howsuch checks can be automated and constructed using rigorousformal semantics, before devices are powered or deployed.Lack of formal policy modeling capabilities in currentnetwork configuration systems contribute to the frequent mis-configurations found [22], [23], [30].A metagraph is a generalized graph theoretic structure thatoffers rigorous formal foundations for modeling and analyzingcommunication-network policies in general. We use them hereto model and analyze MUD policies. A metagraph is a directedgraph between a collection of sets of ‘atomic’ elements [2].Each set is a node in the graph and each directed edgerepresents the relationship between the sets. Figure 1 shows
TABLE I:
Flows observed for Blipcare BP monitor (*:wildcard, proto: Protocol, sPort: source port number, dPort:destination port number).
Source Destination proto sPort dPort * 192.168.1.1 17 * 53192.168.1.1 * 17 53 ** tech.carematix.com 6 * 8777tech.carematix.com * 6 8777 * an example where a set of users ( U ) are related to sets ofnetwork resources ( R , R , R ) by the edges e , e and e describing which user u i is allowed to access resource r j .Metagraphs can also have attributes associated with theiredges. An example is a conditional metagraph which includespropositions – statements that may be true or false – assignedto their edges as qualitative attributes [2]. The generating setsof these metagraphs are partitioned into a variable set and aproposition set. A conditional metagraph is formally definedas follows: Definition 1 (Conditional Metagraph) . A conditional meta-graph is a metagraph S = (cid:104) X p ∪ X v , E (cid:105) in which X p is a setof propositions and X v is a set of variables, and:1. at least one vertex is not null, i.e., ∀ e (cid:48) ∈ E, V e (cid:48) ∪ W e (cid:48) (cid:54) = φ
2. the invertex and outvertex of each edge must be disjoint, i.e., X = X v ∪ X p with X v ∩ X p = φ
3. an outvertex containing propositions cannot contain otherelements, i.e., ∀ p ∈ X p , ∀ e (cid:48) ∈ E , if p ∈ W e (cid:48) , then W e (cid:48) = p . Conditional metagraphs enable the specification of statefulnetwork-policies and have several useful operators. Theseoperators readily allow one to analyze MUD policy propertieslike consistency. To the best of our knowledge, this is thefirst attempt for automatic generation of MUD profile andalso formally check for consistency and its compatibility withan organizational policy prior to installing the access controlrules. III. MUD P
ROFILE G ENERATION
The IETF MUD specification is still evolving as a draft.Hence, IoT device manufacturers have not yet provided MUDprofiles for their devices. We, therefore, developed a tool –
MUDgee – which automatically generates a MUD profile foran IoT device from its traffic trace in order to make this processfaster, cheaper and more accurate. In this section, we describethe structure of our open source tool [8], apply it to traces of28 consumer IoT devices, and highlight insights.We captured traffic flows for each IoT device during a sixmonth observation period, to generate our MUD rules. Therules reflect an application whitelisting model ( i.e., there areno explicit ‘drop’ rules). Having a combination of ‘accept’and ‘drop’ rules requires a notion of rule priority ( i.e., order)and is not supported by the current IETF MUD draft. Forexample, Table I shows traffic flows observed in our lab fora Blipcare blood pressure monitor. The device only generatestraffic whenever it is used. It first resolves its intended server at tech.carematrix.com by exchanging a DNS query/re-sponse with the default gateway ( i.e., the top two flows). Itthen uploads the measurement to its server operating on TCPport 8777 (described by the bottom two rules).2 : min. age of device flow rules
Install bidirectional flow rule with forward actionYes NoNo
DNS reply !" $%&'(& : store domain name and associated IP addr
Yes
Pkt.
Remove the flow rule ) ∈ ) +,- ) >/ 012 23456 ) 73 71 213 $%&'(&
012 ) -89:;271, 2345<73 71 =; = 73 3-4 ?) 0:: ):?@3}
Yes
NTP/ ICMP/ DNS request
IP exists in !" $%&'(&
No Label the Pkt asunicast, multicast, or broadcastChecks
TCP SYN
Read PCAPLoop till EOF • identify direction (from/to device) • identify type (local/Internet)
Remove the flow rule ) ∈) dstIp ) isnot in 213 $%&'(&
012 ) ℎ03 4ℎ-:?@-34 K?:;L-(%)9?14P7Q;47?1 in the direction
Fig. 2:
Algorithm for capturing device flows and inserting reactive rules.
TABLE II:
Proactive flow rules for an IoT device. id sEth dEth typeEth Source Destination proto sPort dPort priority action a < gwMAC > < devMAC > * * 1 * * 100 forwardb.1 < devMAC > < gwMAC > * * 1 * * 100 mirrorb.2 < devMAC > < gwMAC > * * 58 * * 100 mirrorc < gwMAC > < devMAC > * * 17 123 * 100 forwardd.1 < gwMAC > < devMAC > * * * 17 53 * 100 mirrord.2 < devMAC > < gwMAC > * * * 17 * 53 100 mirrore.1 * < devMAC > * * * * * 100 forwarde.2 < devMAC > * * * * * * 100 forwardf < gwMAC > < devMAC > * gw local IP * * * * 90 forwardg < devMAC > < gwMAC > * * gw local IP * * * 90 forwardh < devMAC > * * * * * * 3 forwardi < devMAC > * * * * * * * 2 mirrorj * < devMAC > * * * * * * 2 mirror A. MUDgee ArchitectureMUDgee implements a programmable virtual switch(vSwitch) with a header inspection engine attached and playsan input PCAP trace (of an arbitrary IoT device) into theswitch.
MUDgee has two separate modules; (a) captures andtracks all TCP/UDP flows to/from device, and (b) composesa MUD profile from the flow rules.
Capture intended flows:
Consumer IoT devices use servicesprovided by remote servers on the cloud and also expose ser-vices to local hosts ( e.g., a mobile App). We track (intended)device activities for both remote and local communicationsusing separate flow rules.It is challenging to capture services ( i.e., especially thoseoperating on non-standard TCP/UDP ports) that a device iseither accessing or exposing. This is because local/remoteservices operate on static port numbers whereas source portnumbers are dynamic (and chosen randomly) for differentflows of the same service. Also, inferring the direction of UDPflows is non trivial, though for TCP flows it can be deduced byinspecting the SYN flag. We developed an algorithm (Fig. 2)to capture bidirectional flows for an IoT device.We first configure the vSwitch with a set of proactive rules,each with a specific action ( i.e., “forward” or “mirror”) anda priority. These rules are listed in Table II. Proactive ruleswith a ‘mirror’ action will feed the header inspection enginewith a copy of the matched packets. Our inspection algorithm,shown in Fig. 2, will insert a corresponding reactive rule intothe vSwitch. For example, a DNS reply packet is matched to a top priorityflow ( i.e., flow id ‘d.1’ in Table II) and our algorithm extractsand stores the domain name and its associated IP address intoa DNS cache table. This cache is dynamically updated uponarrival of a DNS reply matching an existing request.The MUD specification requires the segregation of traffic toand from a device for both local and Internet communications.Our algorithm achieves this by assigning a unique priority tothe reactive rules associated with each of the groups: from-local, to-local, from-Internet and to-Internet. We use a specificpriority for flows that contain a TCP SYN to identify if thedevice or the remote entity initiated the communication.Table III shows the flow rules captured for an Awair airquality monitor. The device uses the local gateway and theGoogle DNS server ( i.e., pool.net.org .The IoT device does not have any local communication andonly uses TCP for remote communication.
Flow translation to MUD:
MUDgee uses the captured trafficflows to generate the MUD profiles for the devices by consid-ering the following:
Consideration 1 : We use the DNS cache to reverse lookupthe IP address of the remote endpoint to a domain name, ifany.
Consideration 2 : Some consumer IoTs, especially IP cam-eras, typically use the
STUN! ( STUN! ) protocol to verifythat the user’s mobile app can stream video directly from thecamera over the Internet. If a device uses the STUN protocol3
ABLE III:
Awair air quality reactive flow rules sEth dEth typeEth Source Destination proto sPort dPort priority < devMAC > ff:ff:ff:ff:ff:ff 0x0006 * * * * * 102 < devMAC > ff:ff:ff:ff:ff:ff 0x0800 * 255.255.255.255 17 * 67 102 < devMAC > < gwMAC > * 8.8.8.8 17 * 53 101 < devMAC > < gwMAC > * 192.168.1.1 17 * 53 101 < devMAC > < gwMAC > * pool.ntp.org 17 * 123 101 < gwMAC > < devMAC > < gwMAC > < devMAC > < gwMAC > < devMAC > * 17 123 * 101 < devMAC > < gwMAC > * ota.awair.is 6 * 443 32 < devMAC > < gwMAC > * timeserver.awair.is 6 * 443 32 < devMAC > < gwMAC > * api.awair.is 6 * 443 32 < devMAC > < gwMAC > * messaging.awair.is 6 * 8883 32 < gwMAC > < devMAC > * 6 443 * 21 < gwMAC > < devMAC > * 6 443 * 21 < gwMAC > < devMAC > * 6 443 * 21 < gwMAC > < devMAC > * 6 8883 * 21 over UDP, we must allow all UDP traffic to/from Internetservers because the STUN servers often require the clientdevice to connect to different IP addresses or port numbers. Consideration 3 : We observed that several smart IP camerascommunicate with many remote servers operating on thesame port ( e.g.,
August doorbell camera). However, no DNSresponses were found corresponding to the server IP addresses.So, the device must obtain the IP address of its servers via anon-standard channel ( e.g., the current server may instruct thedevice with the IP address of the subsequent server). For thiscase, we allow remote traffic to/from any IP addresses ( i.e., *), but use a specific port number.
Consideration 4 : Some devices ( e.g.,
TPLink plug) use thedefault gateway as the DNS resolver, and others ( e.g.,
BelkinWeMo motion) continuously ping the default gateway. Theexisting MUD draft maps local communication to fixed IPaddresses through the controller construct. We consider thelocal gateway to act as the controller, and use the name-space urn:ietf:params:mud: gateway for the gateway.The generated MUD profiles of the 28 consumer IoT deviceswe analyzed are listed in Table IV and are publicly availableat: http://149.171.189.1/mud/ . B. Insights and challenges
The Sankey diagrams [24] in Figure 3 represent the MUDprofiles for three IoT devices, namely Blipcare BP monitor,TP-Link camera and Amazon Echo.The Blipcare BP monitor is an example device with staticfunctionalities. It exchanges DNS queries/responses with thelocal gateway and communicates with a single domain nameover TCP port 8777. So its behavior can be locked down to alimited set of static flow rules. The majority of IoT devices thatwe tested ( i.e.,
22 out of 28) fall into this category (markedin green in Table IV).Fig. 3(b) exemplifies the second category of our generatedMUD profiles. The TP-Link camera accesses/exposes limitedports on the local network. It gets its DNS queries resolved,discovers local network using mDNS service over UDP 5353,probes members of certain multicast groups using IGMP, andexposes two TCP ports 80 (management console) and 8080(unicast video streaming) to local devices. All these activitiescan be defined by a tight set of ACLs. But, over the Internet,the camera communicates to its STUN server (accessing an
TABLE IV:
List of IoT devices for which we have generatedMUD profiles. Devices with purely static functionality aremarked in green. Devices with static functionality that isloosely defined ( e.g., due to use of STUN protocol) are markedin blue. Devices with complex and dynamic functionality aremarked in red.
Type IoT device
Camera Netatmo Welcome, Dropcam, Withings SmartBaby Monitor, Canary camera, TP-Link DayNight Cloud camera, August doorbell camera,Samsung SmartCam, Ring doorbell, BelkinNetCamAir qualitysensors Awair air quality monitor, Nest smoke sensor,Netatmo weather stationHealthcaredevices Withings Smart scale, Blipcare BloodPressure meter, Withings Aura smart sleepsensorSwitches andTriggers iHome power plug, WeMo power switch,TPLink plug, Wemo Motion SensorLightbulbs Philips Hue lightbulb, LiFX bulbHub Amazon Echo, SmartThingsMultimedia Chromecast, Triby SpeakerOther HP printer, Pixstar Photoframe, Hello Barbie arbitrary range of IP addresses and port numbers shown bythe top flow), to port numbers on specific endpoints includingtime synchronization with pool.ntp.org . Such IoT deviceswith static functionalities that are loosely defined, due to use ofSTUN protocol fall in to this second category (marked in bluein Table IV). This category device manufacturers can configuretheir STUN servers to use a specific set of endpoints and portnumbers, instead of a wide and arbitrary range.Amazon Echo, represents devices with complex and dy-namic functionalities augmentable using custom recipes orskills. Such devices (marked in red in Table IV), are ableto communicate with a growing range of endpoints on theInternet, which the original manufacturer cannot define inadvance. For example, our Amazon Echo communicates with meethue.com over TCP 443, to interact with the Huelightbulb in the test bed. It can also contact the news website abc.net.au when prompted by the user. For these typeof devices, the biggest challenge is how manufacturers candynamically update their MUD profiles to match the devicecapabilities.4 䰀䤀倀䌀䄀刀䔀 䈀倀 䴀䔀吀䔀刀 (a) Blipcare BP monitor. 吀倀䰀䤀一䬀 䌀䄀䴀䔀刀䄀 (b) TP-Link camera. 䄀䴀䄀娀伀一 䔀䌀䠀伀 (c) Amazon Echo.
Fig. 3:
Sankey diagram of MUD profile for: (a) Blipcare BP monitor, (b) TP-Link camera, and (c) Amazon Echo.
IV. MUD
PROFILE VERIFICATION
Network operators should not automatically implement adevice’s MUD policy without first checking its validity. Lackof rigorous policy verification in current network-configurationsystems is a key contributor to the configuration errors com-monly found [23], [30]. We describe here in detail, theverification steps we apply on a device MUD profile to ensureonly policies that adhere to the IETF MUD specification andare semantically correct are deployed to a network.
A. Syntactic correctness
A MUD profile consists of a YANG model which describesdevice-specific network behavior. In the initial version ofMUD, this model is serialized using JSON [11]. JSON offersmore compactness and readability, relative to XML. A MUDprofile is limited to the serialization of only a few YANGmodules ( e.g., ietf-access-control-list) [11].
MUDdy will throwan invalid syntax exception when parsing a MUD profileif it encounters any schema beyond these permitted YANGmodules.In addition,
MUDdy also rejects MUD profiles containingIP addresses (in particular those with local significance). Asper the IETF specification, publishers of MUD profiles areadvised to use the abstractions provided in the specificationand avoid using IP addresses.
MUDdy will also reject a MUDprofile if it contains actions other than ”accept” or ”drop”.
B. Semantic correctness
Checking a MUD policy’s syntax partly verifies its correct-ness. A syntactically correct policy must also be semanticallycorrect for it to be well designed. For instance, it is necessaryto check a MUD policy for inconsistencies.Inconsistencies in a MUD policy can stem from twosources; (a) due to overlapping rules with different access-control actions; and/or (b) due to overlapping rules withidentical actions. In the absence of rule ordering (as in thecase of the IETF MUD specification), the former set of rulesdepict ambiguous intent of the policy authors. We refer to suchrules as intent-ambiguous rules . Rule order is irrelevant for thelatter type of rules which associate a clear (single) outcome.We refer to such rules as redundancies .Inconsistencies in a security policy can produce unintendedconsequences [29]. So, correct MUD policy deployment de-mands the ability to check for inconsistencies accurately. Wedo so by modeling MUD policies using metagraphs and thenapplying the readily available metagraph algebras.
1) Policy modeling:
Access-control policies are commonlyrepresented using the five-tuple: source/destination address,protocol, source/destination ports [5], [10], [18]. We constructmetagraph models for the MUD policies leveraging this idea.A representative example from our case study is shown inFigure 4. Here, the source/destination addresses are repre-sented by the labels device , local-network , local-gateway and5 ig. 4: Metagraph model of a Lifx bulb’s MUD policy. Thepolicy describes permitted traffic flow behavior. Each edgelabel depicts a set of propositions of the metagraph. For ex-ample e = { protocol = 17 , U DP.dport = 53 , U DP.sport =0 − , action = accept } . a domain-name ( e.g., pool.ntp.org ). Protocol, ports and timeare propositions of the conditional metagraph.
2) Policy definition and verification:
We wrote
MGtoolkit [20] – a package for implementing metagraphs – to define ourpolicy models.
MGtoolkit is implemented in Python 2.7. TheAPI allows users to instantiate metagraphs, apply metagraphoperations and evaluate results.
Mgtoolkit provides a
ConditionalMetagraph class which extends a
Metagraph and supportsproposition attributes in addition to variables. A
ConditionalMetagraph inherits the base properties andmethods of a
Metagraph and additionally supports methodsto check reachability properties and consistency properties.We use the
ConditionalMetagraph class to instantiatethe MUD policy models in § IV-B1. We then invoke the APImethods to check policy properties such as consistency.Our verification of metagraph consistency uses dominance [2] which can be introduced constructively as follows:
Definition 2 (Edge-dominant Metapath) . Given a metagraph S = (cid:104) X, E (cid:105) for any two sets of elements B and C in X , ametapath M ( B, C ) is said to be edge-dominant if no propersubset of M ( B, C ) is also a metapath from B to C . Definition 3 (Input-dominant Metapath) . Given a metagraph S = (cid:104) X, E (cid:105) for any two sets of elements B and C in X , ametapath M ( B, C ) is said to be input-dominant if there is nometapath M (cid:48) ( B (cid:48) , C ) such that B (cid:48) ⊂ B . In other words, edge-dominance (input-dominance) ensuresthat none of the edges (elements) in the metapath is super-fluous. Based on these concepts, a dominant metapath canbe defined as follows. A non-dominant metapath indicatesredundancy in the policy represented by the metagraph.
Definition 4 (Dominant Metapath) . Given a metagraph S = (cid:104) X, E (cid:105) for any two sets of elements B and C in X , ametapath M ( B, C ) is said to be dominant if it is both edgedominant and input-dominant. The potential ‘conflict set’ of propositions in a metapath M ( B, C ) can also be defined as follows: Definition 5 (Conflict-set of Propositions) . Given a condi-tional metagraph S = (cid:104) X v ∪ X p , E (cid:105) for any two sets of elements B and C in X , a metapath M ( B, C ) has the potential conflictset of propositions given by ( (cid:83) e ∈ M ( B,C ) V e ) ∩ X p . Once a conflict set is identified we can apply domain-specific knowledge to determine intent-ambiguous rules ina MUD policy. For instance, with access-control policiessuch rules occur when flows overlap and associate differentresponse actions ( e.g., accept and drop ).
3) Compatibility with best practices:
Policy consistencychecks partly verify if a MUD policy is semantically correct. Itmay also be necessary to check MUD policy semantics againstindustry recommended practices: e.g.,
ANSI/ISA- 62443-1-1,for compliance. Doing so, is critical when installing an IoTdevice in a SCADA network. where more restrictive practicesare required to prevent serious injury of people, or even death!SCADA best practices offer a wide spectrum of securitypolicies, representative of various organizations, to compareour MUD policies against. For instance, they include policiesfor the highly protected SCADA zone (which for instanceruns a power plant) as well as the more moderately restrictiveCorporate zone.We have investigated the problem of policy comparisonusing formal semantics, in the SCADA domain for firewallaccess-control policies [21]. We adapt the methods and al-gebras developed there, to also check MUD policies againstSCADA best practices. Key steps enabling these formal com-parisons are summarized below.Equivalent MUD policies can be specified in many ways.Figures 5(a) and 5(b) illustrate the idea using TCP port filteringof single packets. Each rectangle indicates the allowed packetsof a single rule. Combined the rules cover the same set ofaccepted packets.An efficient approach to comparing these policies accuratelyis by deriving a unique, canonical representation of each MUDpolicy. We dissect the polygon formed in our example policyinto horizontal partitions (Figure 5(c)), using a Rectilinear-Polygon to Rectangle conversion algorithm [7]. Each partitionis chosen to provably guarantee its uniqueness. CanonicalMUD policy elements are derived by translating each partitionback to a rule and ordering the resulting rule-set uniquelyin increasing IP protocol number and source and destinationport numbers. We find a unique partition quickly rather thana guaranteed minimal partition. The result is a deterministic,ordered set of non-overlapping rules.Canonicalisation of policies can be represented through amapping c : Φ → Θ , where Φ is the policy space and Θ is thecanonical space of policies, in which all equivalent policies of Φ map to a singleton. For p X , p Y ∈ Φ , we note the following(the proof follows the definition) Lemma 6.
Policies p X ≡ p Y iff c ( p X ) = c ( p Y ) . So, a MUD policy compliance check can be performed bycomparing canonical policy components. For instanceIs c ( p device → controller ) = c ( p SCADA → Corp ) ?Another useful notation, linked to the goal of policy com-parison, is that policy P A includes policy P B . Particularly in6 a) Four rules indicated by (overlapping) rectangles. (b) Five rules producing an equivalent policy to (a). (c) Horizontal partitions of polygon in (a) or (b). Fig. 5:
Canonicalisation of distinct rule sets of the same MUD policy. Rectangles indicate the packets allowed by a particularrule.
SCADA networks, the notation helps evaluate whether a MUDpolicy is compliant with industry-recommended practices in[4], [27]. These guidelines specify potentially dangerous ser-vices ( e.g.,
HTTP) that should be prohibited from traversinginbound and/or outbound from the (protected) SCADA zone.A violation here, means installing the IoT device increases thevulnerability of a SCADA zone to cyber attacks.We indicate that a policy complies with another if it is morerestrictive and define the following
Definition 7 (Inclusion) . A policy p X is included in p Y on A iff p X ( s ) ∈ { p Y ( s ) , φ } , i.e., X either has the same effect as Y on s , or denies s , for all s ∈ A . We denote inclusion by p X ⊂ p Y . A device MUD policy (
M P ) can now be checked againsta best practice policy ( RP ) for compliance using an inclusioncheck Is p MP ⊂ p RP ?The above approach can likewise be used to check MUDpolicies against an organisation’s internal security policy. Bydoing so, we can ensure that IoT devices are plug and playenabled, only in the compatible zones of a company’s network.V. E VALUATION OF R ESULTS
We ran our system on a standard desktop computer ( e.g.,
Intel Core CPU 2.7-GHz computer with 8GB of RAM runningMac OS X). It was used to generate the MUD files for 28IoT devices in our test bed. Each MUD file policy was thenmodeled using a conditional metagraph and instantiated using
MGtoolkit . A high-level summary of these MUD files and theirmetagraphs are given in Table V.As the table shows, MUD file LoC is a good indicator ofpolicy complexity. For instance, a Chrome cast device has3863 LoC in its MUD file while a Lifx bulb only has 374 LoC.The result indicates the former policy is more complex. Ametagraph helps to visualize this increase in policy complexitymore easily. The resemblance of a metagraph to a networkallows one to exploit the pattern recognition capabilities of thehuman visual cortex to better visualize policies. For instance,compare the policy metagraph of a Chrome cast device inFigure 6 against that of the Lifx bulb in Figure 4. One caneasily understand the increase in size and complexity of theformer policy relative to the latter, by simply inspecting thetwo metagraphs. We identified inconsistencies in the MUD policies using themetagraph algebras defined in § IV-B2. There were no intent-ambiguous rules found since the MUD files were generatedusing an application whitelisting model ( i.e., restricting toaccept rules). However, redundancies are still possible andTable V shows the redundancies found. For instance, therewere three redundant rules in the Belkin camera’s MUD policy(Table V). These rules enabled ICMP traffic to the devicefrom the local network as well as the local controller, makingthe policy inefficient. We determined these redundancies bycomputing non-dominant metapaths in the policy metagraphs(as per Definition 4).Table V also shows the results of our best practice com-pliance checks of the MUD policies. For instance, a Blipcareblood pressure monitor can be safely installed in the Demilita-rized zone (DMZ) or the Corporate zone in a network, but notin the SCADA zone. Installing the device in the SCADA zonewould cause 50% of its MUD policy rules to violate the bestpractices (Table V), exposing the zone to cyber attacks. Theviolation is due to policy rules which enable DNS from thedevice or enable the device to communicate with the Internetdirectly.In comparison, an Amazon echo speaker can only be safelyinstalled in the DMZ of a network. Table V shows that 29% ofthe device’s MUD policy rules violate the best practices if it’sinstalled in the SCADA zone. Only 2% of the rules violate ifit’s installed in the Corporate zone. The former violation stemsfrom policy rules which for instance, enable HTTP inboundto the device. The latter stems from rules which enable ICMPinbound to the device from the Internet.
MUDdy ’s ability to pinpoint to MUD rules which cause bestpractice violations, helps us to identify possible workaroundsto achieve compliance. For instance, with the Belkin camera,local DNS servers and Web servers can be employed tolocalize the device’s DNS and Web communications andovercome the violations.VI. D
ISCUSSION
Our use of an application whitelisting model in generatinga MUD profile, eliminates intent-ambiguous rules by designand reduces potential inconsistencies to just redundancies.Thus, the effort required to check MUD policy consistencyis reduced. Moreover, the use of explicit ‘drop’ rules requiresconsidering rule order to determine correct policy outcome.7 ig. 6:
Metagraph model of a Chrome cast device’s MUD policy. The policy describes permitted traffic behavior.
TABLE V:
MUD policy analysis summary for our test bed IoT devices (
Safe to install? indicates where in a network ( e.g.,
Enterprise Zone, SCADA Zone, DMZ) the device can be installed without violating best practices, LoC - Lines of Code, DMZ- Demilitarized Zone, Corp Zone - Enterprise Zone).
Device name ig. 7: Metagraph model of a Samsung smart camera’s MUD policy. The policy describes permitted traffic (black edges) anddenied traffic (red edges) behavior. Each label edge depicts a set of propositions of the metagraph. For example e = { protocol =1 , action = drop } . The requirement increases policy specification complexitywithout any real benefit.Drop rules also make policy visualization more difficult.Consider the metagraph in Figure 7 which describes a MUDpolicy containing accept and drop rules. Each metagraph edgedescribes an enabled traffic flow, when a whitelisting model isadopted. The absence of an edge implies two metagraph nodesdon’t communicate with one another. But when drop rulesare introduced, an edge now additionally describes prohibitedtraffic flows between the nodes. This hinders easy visualizationand understanding of a MUD policy.Restricting to accept rules (with a default drop-all rule)renders rule order irrelevant. A MUD policy holds the samesemantics, irrespective of how rules are organized, removingdependencies from the policy specification. A policy authorcan then add or remove a rule without considering the com-plete rule set and the potential interactions. We recommend theIETF MUD specification be revised to only support explicit‘accept’ rules.Our suit of tools also allow one to check a MUD policy iscompliant with an organizational policy, prior to deployment.This ability reduces the effort required to acceptance-test anIoT device because we need not test the device in networksegments where its MUD policy fails to comply with theorganizational policy.The IETF MUD specification also advises publishers ofMUD profiles to use abstractions provided and avoid using IPaddresses. But upon clarification with the specification authors,we found that the use of public IP addresses is still permitted.This relaxation of the rule allows close coupling of policy withnetwork implementation, increasing its sensitivity to networkchanges. A MUD policy describes IoT device behavior and should only change when its actual behavior alters and not dueto changes to network implementation! Hardcoded public IPaddresses can also lead to DoS of target hosts. A good exampleis the DoS of NTP servers at the University of Wisconsindue to hardcoded IP addresses in Netgear routers [19]. Werecommend that support for explicit IP addresses (public orprivate) be dropped from the MUD specification.VII. C
ONCLUSION AND F UTURE W ORK
The Internet of Things interconnects billions of every daydevices to the Internet, integrating the physical and cyberworlds. But, increased interconnectivity also increases theexposure of these devices to unwanted intrusions. The IETFMUD proposal aims to reduce the threat surface of an IoTdevice to what is intended by the manufacturer.In this paper, we propose a suite of tools that allow toautomatically generate and formally verify IoT device MUDprofiles, to ensure the MUD policies are consistent and com-patible with organizational policies. We use these tools todemonstrate how MUD can reduce the effort needed to secureIoT devices. R
Metagraphs and their applications , vol-ume 15. Springer Science & Business Media, 2007.[3] S. Boddy and J. Shattuck. The Hunt for IoT: The Rise of Thingbots.Technical report, F5 Labs, July 2017.[4] E. Byres, J. Karsch, and J. Carter. NISCC good practice guide on firewalldeployment for SCADA and process control networks.
NISCC , 2005.[5] Cisco Systems.
Cisco ASA Series CLI Configuration Guide, 9.0 . CiscoSystems, Inc., 2013.[6] FCC. Federal Communications Comssion Response 12-05-2016. https://goo.gl/JdLofa, 2016.
7] K. D. Gourley and D. M. Green. Polygon-to-rectangle conversionalgorithm.
IEEE CGA , pages 31–32, 1983.[8] A. Hamza. MUDgee. https://github.com/ayyoob/mudgee, 2018.[9] S. Hilton. Dyn Analysis Summary Of Friday October 21 Attack. https://goo.gl/mCdQUF, 2016.[10] Juniper Networks, Inc.
Getting Started Guide for the Branch SRX Series .1133 Innovation Way, Sunnyvale, CA 94089, USA, 2016.[11] E. Lear, R. Droms, and D. Romascanu. Manufacturer usage descriptionspecification (work in progress). Internet-Draft draft-ietf-opsawg-mud-18, IETF Secretariat, January 2018.[12] F. Loi, A. Sivanathan, H. H. Gharakheili, A. Radford, and V. Sivaraman.Systematically evaluating security and privacy for consumer iot devices.In
Proc. ACM IoT S&P
CoRR
PAN-OS Administrator’s Guide, 8.0 ∼ plonka/netgear-sntp/, 2013.[20] D. Ranathunga, H. Nguyen, and M. Roughan. Mgtoolkit: A pythonpackage for implementing metagraphs. SoftwareX , 6:91–93, 2017.[21] D. Ranathunga, M. Roughan, P. Kernick, and N. Falkner. Malachite:Firewall policy comparison. In
IEEE Symposium on Computers andCommunication (ISCC) , pages 310–317, June 2016.[22] D. Ranathunga, M. Roughan, P. Kernick, N. Falkner, H. Nguyen, M. Mi-hailescu, and M. McClintock. Verifiable policy-defined networking forsecurity management. In
SECRYPT , pages 344–351, 2016.[23] D. Ranathunga, M. Roughan, H. Nguyen, P. Kernick, and N. Falkner.Case studies of scada firewall configurations and the implications forbest practices.
IEEE Transactions on Network and Service Management ,13:871–884, 2016.[24] M. Schmidt. The sankey diagram in energy and material flow manage-ment.
Journal of industrial ecology , pages 82–94, 2008.[25] A. Sivanathan, D. Sherratt, H. H. Gharakheili, A. Radford, C. Wije-nayake, A. Vishwanath, and V. Sivaraman. Characterizing and classify-ing iot traffic in smart cities and campuses. In
Proc. IEEE INFOCOMworkshop on SmartCity , Atlanta, Georgia, USA, May 2017.[26] V. Sivaraman, D. Chan, D. Earl, and R. Boreli. Smart-phones attackingsmart-homes. In
Proceedings of the 9th ACM Conference on Security &Privacy in Wireless and Mobile Networks , pages 195–200. ACM, 2016.[27] K. Stouffer, J. Falco, and K. Scarfone. Guide to Industrial ControlSystems (ICS) security.
NIST Special Publication , 800(82):16–16, 2008.[28] C. Systems. Cisco 2018 Annual Cybersecurity Report. Technical report,2018.[29] A. Wool. A quantitative study of firewall configuration errors.
IEEEComputer , 37(6):62–67, 2004.[30] A. Wool. Trends in firewall configuration errors: Measuring the holesin Swiss cheese.
IEEE Internet Computing , 14(4):58–65, 2010.[31] P. World. Backdoor accounts found in 80 Sony IP security cameramodels. https://goo.gl/UUvc2x, 2018., 14(4):58–65, 2010.[31] P. World. Backdoor accounts found in 80 Sony IP security cameramodels. https://goo.gl/UUvc2x, 2018.