A0015: Switch
A switch is a network device that connects endpoints (e.g., workstations, servers, HMIs, PLCs, etc.) so that they can communicate and share data and resources. Switches may operate at either Layer 2 or Layer 3 of the OSI Model and intelligently forward packets across the network based on the specified address (Media Access Control (MAC) address for Layer 2 and Internet Protocol (IP) address for Layer 3). Switches are typically used to define network segments and connect the devices within a particular level of the Purdue Model.
Security context for executives and security teams
In an ICS environment, a switch is not just “network plumbing.” It connects HMIs, PLCs, workstations, servers, and other endpoints inside Purdue Model levels, so compromise, misconfiguration, or disruption can affect visibility, control traffic, segmentation, and operational continuity. Because ATT&CK relationships show many adversary behaviors targeting switches, leaders should treat switch management, monitoring, and recovery as part of OT resilience—not only network administration.
Executive priority
Prioritize switches as critical shared infrastructure for ICS availability and segmentation. Executive questions should include: Which switches define or connect key Purdue Model segments? Who can administer them locally or remotely? Are default or shared credentials eliminated? Can the team prove configuration integrity and recover quickly after destructive change, restart, shutdown, or denial-of-service conditions? This matters for incident decision-making, audit evidence, vulnerability prioritization, and cyber-physical risk where network disruption could affect process visibility or control.
Technical view
SOC, detection engineering, and IR teams should validate monitoring around both the data plane and management plane of embedded/network switches. The relationship context indicates relevant behaviors include CLI and GUI access, valid accounts, external remote services, remote service exploitation, discovery through port scans/broadcast/multicast, network sniffing, adversary-in-the-middle activity, standard application layer protocol use, scripting/API/native API activity, indicator removal, rootkit/hooking-style concealment, data destruction, restart/shutdown, denial of service, and supply chain compromise. Since ATT&CK provides no official detection text for this asset, coverage should be proven locally through logs, network evidence, configuration baselines, and incident response exercises.
Likely telemetry
- Switch management access logs for CLI, GUI, and remote administration where available
- Authentication and account-use records for administrative and service accounts
- Configuration change history, startup/running configuration backups, and integrity comparisons
- Network flow records and packet captures around switch-connected segments
- Evidence of port scanning, broadcast discovery, and multicast discovery on ICS subnets
Detection direction
- Start by mapping which switches connect critical ICS assets and Purdue Model levels, then validate that monitoring covers those segments and management interfaces.
- Tune for unusual administrative access patterns: unexpected CLI/GUI sessions, remote service use, new source locations, abnormal timing, or account use inconsistent with maintenance windows.
- Baseline normal ICS discovery and management traffic before alerting on scans, broadcast discovery, multicast discovery, or standard application layer protocols to reduce false positives from legitimate engineering tools.
- Correlate network symptoms with device evidence: DoS, restart/shutdown, AiTM, and sniffing-related activity may appear first as traffic anomalies, loss of connectivity, or unexpected forwarding behavior.
- Validate configuration integrity detection, because destructive changes or indicator removal may reduce the usefulness of on-device logs after compromise.
Mitigation priorities
- Maintain an authoritative inventory of ICS switches, their Purdue Model role, connected critical assets, management interfaces, firmware/software state, and approved administrators.
- Restrict switch administration paths, especially external remote services, and separate routine user traffic from management access where the environment supports it.
- Strengthen identity controls for switch administration: remove default credentials, limit privileged accounts, and review valid-account use tied to maintenance activity.
- Keep recoverable configuration backups and tested restoration procedures for destructive change, restart/shutdown events, and availability incidents.
- Prioritize vulnerability management for exposed remote services and embedded/network switch software based on operational criticality and reachable attack surface.
Additional notes and limits
This take is based on the ATT&CK ICS asset A0015 Switch and its supplied relationships. The object describes switches as Layer 2 or Layer 3 network devices connecting endpoints such as workstations, servers, HMIs, and PLCs, commonly used to define network segments and connect devices within Purdue Model levels. Relationship-driven context shows a broad set of techniques targeting this asset, so defensive value comes from validating management-plane security, network visibility, configuration integrity, and recovery readiness.
MITRE provides no official detection guidance for this asset, and tactics are not specified in the supplied object. The related technique descriptions support risk themes but do not prove any specific environment is exposed or that any control is effective. Local architecture, switch capabilities, logging configuration, remote access design, and operational constraints are required to determine actual coverage and priority.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Switch
A switch is a network device that connects endpoints (e.g., workstations, servers, HMIs, PLCs, etc.) so that they can communicate and share data and resources. Switches may operate at either Layer 2 or Layer 3 of the OSI Model and intelligently forward packets across the network based on the specified address (Media Access Control (MAC) address for Layer 2 and Internet Protocol (IP) address for Layer 3). Switches are typically used to define network segments and connect the devices within a particular level of the Purdue Model.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates.
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.