PaperlayerView exact revision on arXiv

Source-linked AI summary

From Source Code to Network Profile: Automated and Traceable MUD Profile Generation for IoT Devices

Alessandro Lotto, Abdulla R. A. Almenhali, Savio Sciancalepore, Alessandro Brighente, Mauro Conti

arXiv:2609.31594v1cs.CRcs.SE

TL;DR

Traffic-based MUD generation depends on observed communications, which may omit rare or conditional behavior and provide limited insight into its software origins. AutoMUD generates traceable profiles from source code using extraction, retrieval-grounded reasoning, and deterministic validation. On the evaluated benchmark, it recovered source-grounded behavior and generated the expected policy; the authors also identify source-tree availability as a limitation.

  • Problem

    Traffic-based MUD generation requires deployment and prolonged monitoring, yet may miss rare or configuration-dependent communications and offers limited evidence about their software origins.

    Source: §1 · p. 1

  • Method

    AutoMUD combines source-code extraction, retrieval-grounded LLM reasoning, and deterministic validation and compilation to generate traceable MUD rules while retaining unresolved findings for review.

    Source: §1 · p. 2

  • Results

    AutoMUD recovered all source-grounded communication behaviors in the benchmark, generated the expected MUD policy, and preserved complete source-to-rule traceability.

    Source: §7 · p. 13

  • Takeaways & Limitations

    Source-code analysis can complement traffic-based MUD generation by exposing implemented capabilities that may remain unobserved during time-limited monitoring.

    Source: §7 · p. 13

    AutoMUD assumes access to a traversable source tree and relevant configuration evidence, so missing or inaccessible code and build-time values may conceal communication behavior.

    Source: §6.2 · p. 12

Abstract

from arXiv · show

The Manufacturer Usage Description (MUD) standard allows IoT manufacturers to define expected network behaviors in a MUD file. This file can be translated into enforceable access-control policies, restricting compromised devices to operate solely through manufacturer-defined communication patterns. However, practical adoption of MUD depends on profiles that are accurate, complete, and maintainable. Existing approaches use traffic-based automation but require device deployment and prolonged monitoring, capturing only behavior exercised during observation. Rare, failure-triggered, or configuration-dependent communications may remain absent, producing incomplete policies that disrupt legitimate operation and offer limited insight into the software components responsible for each rule. We present AutoMUD, a source-code-driven tool that generates traceable MUD profiles for IoT devices from their firmware and software source code. AutoMUD combines static and syntactic extraction, retrieval-grounded language-model reasoning, and deterministic validation and compilation to recover the communication behavior characterizing an IoT device and translate eligible endpoints into policy rules. By analyzing code-level evidence, AutoMUD exposes rarely exercised and conditional communication paths, links every generated rule to its source-level provenance, and preserves excluded findings with explicit reasons for review. Our evaluation on a Linux-based repository demonstrates that AutoMUD recovers complete communication behavior, consolidates validated behavior into semantic endpoint groups, and generates structurally valid MUD profiles. Through a controlled semantic fault-injection campaign, we demonstrate that AutoMUD enables analysts to detect, localize, explain, and correct propagated errors, recovering policies semantically identical to their clean counterparts.

1 Introduction

MUD adoption is constrained by the difficulty of producing and maintaining accurate profiles, while traffic-based generation can miss behaviors and offers limited evidence about their software origins. AutoMUD instead derives traceable profiles from source code and preserves excluded findings for review.

1 Introduction

  • Traffic-based tools require prolonged monitoring and may miss rare or configuration-dependent communications, leaving legitimate behavior absent from enforced profiles.Traffic traces also provide limited evidence about the software component, configuration, or execution path behind a communication.Source: §1 · p. 1
  • AutoMUD combines static and syntactic extraction, retrieval-grounded LLM reasoning, and deterministic validation and compilation to generate MUD rules from source code.Unresolved or non-representable findings remain available for review rather than becoming permissions.Source: §1 · p. 2
  • The evaluation covers Linux-based codebases and uses controlled semantic fault injection to show that provenance can expose, localize, explain, and support correction of erroneous rules.The evaluation also reports reconstruction of the expected profile while preventing non-endpoint values from becoming permissions.Source: §1 · p. 2

2 The MUD Standard

MUD lets manufacturers describe device communication requirements in a machine-readable profile that a controller translates into enforceable policies. Its file represents permitted communications through ACLs and endpoint abstractions.

2 The MUD Standard

  • MUD is an IETF standard designed to reduce IoT attack surfaces by limiting devices to the network interactions their operational purpose requires.A controller retrieves the device profile and translates it into enforceable policies; undeclared communications are unauthorized.Source: §2 · p. 2
  • A MUD file serializes YANG modules as JSON, with metadata and policy references in its MUD section and permitted communications in ACLs.Each ACE pairs match conditions with an accept-or-drop action.Source: §2 · p. 2
  • ACL match conditions can specify IP family, network protocol, transport ports, and endpoint abstractions, while the referencing policy encodes communication direction.Endpoint abstractions can represent manufacturer peers or services rather than fixed network addresses.Source: §2 · p. 2

3 Related Work

Prior automated MUD generation largely derives rules from observed device behavior, while source-code analysis offers complementary evidence but leaves a semantic gap between extracted code facts and policy-level behavior. AutoMUD combines source extraction with retrieval-grounded reasoning to address that gap.

3 Related Work

  • Traffic-based tools such as MudGee and MUD-PD generate profiles from monitored communications, while active testing refines existing profiles rather than generating them from scratch.Observed-behavior approaches can miss rare or conditional communications and provide limited evidence about the code path responsible for a flow.Source: §3 · pp. 2–3
  • Static source analysis can extract networking calls and track ports, addresses, and configuration values, but those facts alone do not specify MUD-level protocol, transport, role, or direction semantics.Heterogeneous repositories make this semantic interpretation challenging.Source: §3 · p. 3
  • AutoMUD combines deterministic source extraction with retrieval-grounded LLM reasoning to recover MUD-relevant behavior, generate rules, and link included and excluded findings to software evidence.The cited comparison table concerns approaches for automated MUD profile generation.Source: §3 · p. 3, Table 1 · p. 3

4 AutoMUD

AutoMUD analyzes traversable IoT software trees through application-specific workspaces and evidence-preserving stages, producing a MUD profile alongside traceability, validation, and review information. Its design emphasizes recoverable MUD semantics, conservative rule eligibility, and inspectable decisions.

4.1 Design Considerations and Requirements

  • AutoMUD targets heterogeneous source trees and requires recovery of MUD-level behavior, structurally valid profiles, conservative eligibility, and traceable decisions.Only source-supported endpoint records with concrete, internally consistent packet-level semantics may become rules; unresolved findings remain outside the generated policy.Source: §4.1 · p. 3

4.2 Overview

  • The pipeline isolates applications, builds application-specific retrieval indexes, discovers protocols and roles, then consolidates eligible endpoints and synthesizes the MUD file.Excluded or unresolved records remain available through traceability and operator-review artifacts.Source: §4.2 · p. 4

4.3 Application Discovery and Isolation

  • Application discovery uses structural and network-relevance evidence to select coherent workspaces, while retaining source-scope provenance independently from endpoint eligibility.Non-production code can still qualify when it implements externally reachable communication under a supported configuration; disabled, unreachable, loopback-only, or non-representable behavior is ineligible.Source: §4.3 · p. 4

4.4 Retrieval-Oriented Representation

AutoMUD prepares application-specific, source-traceable evidence for retrieval and reasoning, then discovers and validates network candidates using both named constants and connection behavior. Source uses, activation conditions, and deterministic value checks help distinguish supported ports from unresolved or non-port values.

4.4 Retrieval-Oriented Representation

  • Structural chunk metadata remains deterministic and authoritative, while LLM annotations add network-oriented semantics without replacing source identity or establishing unsupported numeric evidence.Inconsistent representations are rejected.Source: §4.4 · pp. 4–5
  • AutoMUD creates an application-specific vector index of enriched source chunks so later queries retrieve compact, relevant evidence with source coordinates.Separate indexes keep unrelated applications from competing during retrieval.Source: §4.4 · pp. 4–5

4.5 Protocol Discovery

  • For each candidate application, adaptive inspection refines retrieval queries using only identifiers found in retrieved evidence before candidate discovery.Inspection allocates analysis effort but does not determine endpoint eligibility.Source: §4.5 · p. 5
  • Constant-oriented parsing and behavior-oriented queries jointly discover named network candidates and configurable or derived connection paths for later eligibility review.Configured, dynamic, and derived endpoints remain classified as such rather than being converted into fixed ports.Source: §4.5 · p. 5
  • A candidate becomes a fixed port only when its value is source-resolved and its uses support port semantics; arithmetic guesses and contradictory control uses are rejected.Exact-symbol searches recover uses across chunk boundaries, while compile-time and runtime guards preserve whether paths are enabled, conditional, disabled, or unresolved.Source: §4.5 · pp. 5–6

4.6 Role Inference

AutoMUD infers client and server direction from source-grounded connection paths, while keeping role, provenance, and transport evidence distinct. Its incremental tracing records the evidence behind role decisions rather than relying on a single model judgment.

4.6 Role Inference

  • AutoMUD traces candidate values through socket fields and networking operations, using connect() evidence for client roles and bind() plus listen() for server roles.Independently evidenced paths can retain both roles, and local listening ports remain distinct from remote service ports.Source: §4.6 · p. 6
  • Role is recorded separately from source scope, so a test server remains role=server and source_scope=test rather than becoming a compound role.This preserves provenance for later eligibility decisions.Source: §4.6 · p. 6
  • A per-candidate ledger aggregates transport evidence across phases, prioritizing direct network-context evidence and requiring corroboration before transport is considered established.Even corroborated evidence must be tied to the specific candidate rather than unrelated infrastructure.Source: §4.6 · p. 6

4.7 Semantic Endpoint Consolidation and MUD File Synthesis

AutoMUD consolidates source-grounded classifications into endpoint records and applies explicit transport and eligibility checks before deterministic policy compilation. The compiler preserves behavioral distinctions and keeps excluded capabilities available for review.

4.7 Semantic Endpoint Consolidation and MUD File Synthesis

  • The endpoint classifier receives source definitions, resolved values, use evidence, connection traces, configuration, inferred roles, and transport evidence, returning normalized records.Accepted outputs can be evaluated independently of preceding LLM reasoning.Source: §4.7 · p. 6
  • Each candidate receives an explicit TCP and UDP disposition; uncertain applicability triggers a bounded reconciliation pass, and unresolved candidates remain reviewable but ineligible for synthesis.Represented transports require endpoint indexes and evidence, while context_only retains evidence that does not apply to the candidate.Source: §4.7 · pp. 6–7
  • Eligibility requires concrete packet semantics, externally reachable and MUD-representable behavior, and successful deterministic validation; unresolved capabilities are not compiled automatically.These gates separate discovery from authorization.Source: §4.7 · p. 7
  • The compiler merges records only when evidence establishes behavioral equivalence, maps client and listening behavior to the corresponding MUD policy direction, and retains excluded records with reasons.Identical ports remain distinct when transport, role, or activation conditions differ.Source: §4.7 · p. 7

4.8 Explainability, Traceability and Validation

AutoMUD emits policy, traceability and validation artifacts, and review artifacts for supported capabilities excluded from automatic compilation. Constrained prompts and cross-artifact checks preserve evidence links and prevent unresolved findings from silently changing policy.

4.8 Explainability, Traceability and Validation

  • AutoMUD produces a standard-compliant MUD file, traceability and validation artifacts, and review artifacts for source-supported capabilities excluded from compilation.The separation keeps excluded or unresolved evidence visible without treating it as enforceable policy.Source: §4.8 · p. 7
  • Each generated ACE links to its normalized endpoint record and the source evidence, values, semantic decisions, and eligibility outcome used to compile it.The intermediate artifacts reconstruct the rule from its generating evidence rather than through post hoc interpretation.Source: §4.8 · p. 7
  • Excluded candidates retain provenance, coded reasons, and recommended verification actions; a candidate ACE preview is offered only when packet semantics are complete.Review artifacts cannot add, remove, or modify automatically generated rules.Source: §4.8 · p. 7
  • Structural checks validate MUD metadata, references, rule fields, address families, transport, ports, and direction, alongside RFC 8520 and RFC 8519 YANG modules.Cross-artifact checks require every generated ACE to map to an eligible record and every excluded record to have an explicit review reason.Source: §4.8 · p. 7

4.9 Prompt Engineering

  • Prompts constrain model outputs to retrieved evidence, task schemas, and closed labels; unresolved transport applicability receives a restricted reconciliation pass or remains excluded.Corroborated evidence cannot be silently omitted, and distinct transport or activation conditions cannot be merged without support.Source: §4.9 · p. 7

5 Experimental Evaluation

The evaluation tests AutoMUD’s end-to-end synthesis, fault diagnosis, and comparison with traffic-based profile generation. Across the evaluated repository, it assesses semantic coverage and traceability, then examines how rare communication patterns affect traffic-based completeness.

5.1 Experimental Setup

  • The evaluation used selected Linux-kernel code with curl, wget, and OpenSSH, plus independently curated retrieval- and policy-level ground truths.The 31-symbol retrieval reference was distinct from endpoint eligibility and policy synthesis; the policy reference contained 23 semantic endpoint groups.Source: §5.1 · p. 8

5.2 End-to-End MUD Synthesis Evaluation

  • AutoMUD generated an RFC 8520-valid profile covering all 23/23 validated endpoint groups in 92 ACEs, matching the reference policy’s semantic rules.All 92 ACEs had rule-level source traceability; non-endpoint implementation values were retained as evidence but excluded from permissions.Source: Table 2 · p. 9, §5.2 · p. 9
  • Across five successful runs, AutoMUD averaged 9 h 48 min of execution time on the 1.4 GB repository.Protocol analysis accounted for 85.5% of aggregate execution time.Source: §5.2 · p. 9

5.3 Controlled Fault Injection and Explainability Evaluation

  • All five injected semantic faults were detected, localized, reconstructed, and corrected to the clean 92-ACE policy without changing unaffected rules.The injected policies remained structurally valid, so the campaign tested semantic diagnosis using AutoMUD’s generated artifacts.Source: §5.3 · p. 10, Table 3 · p. 11

5.4 Comparison to Traffic-based Approaches

  • At 0.95 observation probability per common group, complete-profile recovery is 0.307 with equal rates, but 0.838, 0.0955, or 0.00968 with one low-rate group (α=0.1, 0.01, 0.001).The comparison assumes perfect translation of observed communications; expected group coverage typically remains above 0.90 despite lower complete-profile probability.Source: Figure 2 · p. 11, §5.4 · p. 11
  • The comparison treats traffic traces and source analysis as complementary: traces show exercised communications, while code exposes implemented capabilities.The modeled traffic-based generator perfectly translates observed flows, isolating missed behavior to communications absent during observation.Source: §5.4 · pp. 11–12

6 Discussion

AutoMUD translates source implementation evidence into traceable policy behavior, including capabilities that traffic observation may miss. Its evaluation supports this approach while identifying limits in source availability, benchmark scope, and fault-injection coverage.

6.1 Key Findings

  • AutoMUD recovered all 31 ground-truth symbols and translated 24 source-validated endpoint groups into the expected 92 ACEs, with structural checks and source traceability.The profiles contained no duplicate rules, and every emitted ACE linked to its endpoint record and supporting source evidence.Source: §6.1 · p. 12
  • Source analysis can recover rare, failure-triggered, update-related, or configuration-dependent paths without deploying the device or waiting for each behavior to occur.The paper presents source analysis and traffic observation as complementary: traffic can confirm active flows and deployment-specific peers, while source analysis reveals supported capabilities.Source: §6.1 · p. 12
  • OpenSSH analysis exposed conditional SOCKS and HTTP proxy capabilities while excluding IPPORT_RESERVED and channel-type values 2 and 11 from deployable services.Network-related implementation values do not automatically qualify for production authorization; source scope, activation conditions, and exclusion evidence remain available for review.Source: §6.1 · p. 12
  • Traceability helps investigate incorrect rules because injected semantic inconsistencies reached structurally valid policies but remained inconsistent with retained lower-level evidence.Separating discovery, classification, eligibility assessment, and compilation preserves provenance for emitted rules and findings withheld from compilation.Source: §6.1 · p. 12

6.2 Limitations and Future Work

  • AutoMUD assumes access to a traversable source tree and relevant configuration; missing proprietary components, generated code, libraries, build-time values, or unretrieved regions may conceal behavior.The paper suggests adding public information and traffic-based sources for inaccessible regions.Source: §6.2 · p. 12
  • Evaluation used a privately owned controlled repository, and future work could extend coverage to complete device trees, cross-vendor repositories, more languages and build systems, and non-Linux environments.The inconsistency evaluation also used a bounded set of higher-level semantic faults with contradictory lower-level evidence and a blinded OpenAI Sol analyst.Source: §6.2 · pp. 12–13

7 Conclusions

The conclusion presents AutoMUD as a source-code-driven approach for generating traceable MUD profiles without device deployment or traffic traces. The evaluation reports recovery of benchmark communication behavior and support for correcting semantic policy errors.

7 Conclusions

  • AutoMUD generated the expected MUD policy from benchmark source-grounded communication behaviors while preserving source-to-rule traceability.Unresolved or non-representable findings were retained for further review.Source: §7 · p. 13
  • The controlled fault-injection campaign showed that AutoMUD's produced artifacts can support detection, explanation, and correction of semantic policy errors.Source: §7 · p. 13
  • Source-code analysis can complement traffic-based MUD generation by exposing implemented capabilities that time-limited monitoring may not observe.The paper frames this as a step toward reducing MUD adoption effort and improving policy transparency and maintainability.Source: §7 · p. 13

A LLM Analyst Prompt

The prompt directs an artifact-grounded audit of generated MUD rules, tracing any inconsistency to its source and specifying the correction. The example identifies four structurally valid but semantically unsupported TCP/2 rules and removes them.

A LLM Analyst Prompt

  • The prompt asks the analyst to audit rules against validation, traceability, and review artifacts, trace inconsistencies to candidates, and distinguish direct evidence from inference.It also requests a corrected endpoint representation, the necessary MUD change, and any additional evidence needed.Source: A LLM Analyst Prompt · p. 14
  • The generated MUD is structurally valid but semantically inconsistent: four ACEs authorize TCP port 2 based on an internal OpenSSH channel-type discriminator.The other 92 ACEs have no direct contradiction in the supplied artifacts.Source: A LLM Analyst Prompt · p. 14
  • The macro’s value 2 is not established as a network port: it is classified as an internal discriminator, while the actual forwarding port comes from configuration.The recorded evidence includes no positive port evidence, and the corresponding listener port is configuration-dependent.Source: A LLM Analyst Prompt · p. 14
  • The corrected representation describes a TCP local-forwarding listener with a configured port and rejects it as a fixed-port MUD candidate.Applying configured-port semantics to this exact endpoint is identified as an inference, though those semantics are recorded for the corresponding endpoint.Source: A LLM Analyst Prompt · p. 15
  • Removing the four TCP/2 ACEs reduces the policy from 96 to 92 ACEs; the other 92 ACEs and their traceability records remain consistent.A new rule would require deployment evidence establishing a concrete forwarding port.Source: A LLM Analyst Prompt · p. 15

B Additional Controlled Fault-Injection Cases

Across the injected cases, the analyzer traced errors to their source candidates, explained why numeric values did not establish fixed ports, and corrected the policies to match the clean 92-ACE baseline. The cases include internal channel-type values, a derived X11 port, and an error-code discriminator.

B Additional Controlled Fault-Injection Cases

  • SSH_CHANNEL_RPORT_LISTENER = 11 is an internal channel type, not a port; removing its four TCP/11 ACEs restores the policy to 92 ACEs.The actual remote-forwarding port is obtained from runtime configuration, such as -R or RemoteForward.Source: B Additional Controlled… · p. 15
  • X11_BASE_PORT = 6000 is only the base of a port calculation; without evidence of display number zero, eight fixed TCP/6000 ACEs are unsupported.The effective listener port is X11_BASE_PORT plus display_number; removing those ACEs reduces the policy from 100 to 92 ACEs.Source: B Additional Controlled… · p. 15
  • PE_BAD_PORT_NUMBER = 4 indicates a malformed or out-of-range supplied port, not the contacted port; removing four TCP/4 ACEs restores 92 ACEs.The destination port instead comes from the parsed URL or the relevant protocol default.Source: B Additional Controlled… · p. 15
  • Across all four cases, corrected policies matched the clean 92-ACE baseline, with no unaffected ACE removed or modified.The analyzer identified each injected symbol, traced affected ACEs to originating candidates, explained the evidence, and prescribed corrections.Source: B Additional Controlled… · p. 15

Related papers

Loading 2609.31594v1…