Assessing the security of an industrial switch is not about scoring its enclosure, and it is not about casually scanning the device. It should, within an authorized scope, examine management entry points, communication boundaries, configuration, and recovery capability, while protecting production reliability and safety. Production networks should prioritize low-risk materials, configurations, and passive observation, and should not directly copy attack testing from office networks.
1. First distinguish device management from service forwarding
A switch has service ports that carry device communications, and it also has management entry points for administrators to view status and change configurations. These may use different interfaces or logical addresses. The fact that services can be forwarded normally does not mean the management page is secure; and restricted management login does not mean all service traffic is already controlled. During assessment, these two paths should be drawn separately.
Unauthorized access to a management entry point may lead to changes in VLANs, port status, or ring network settings; on the service side, attention should be paid to which terminals can communicate with each other and whether there is unnecessary cross-zone access. The IP protection rating describes the enclosure’s ability to block foreign objects and water; it does not indicate network security. Repeated enclosure protection paragraphs in the original should be grouped under the corresponding topic, while network security is discussed separately by permissions, boundaries, and operational processes.
2. Authorization and business risk determine the testing method
First confirm the device list, model, firmware, topology, maintenance personnel, production use, and the scope allowed for testing. Clarify which devices cannot be interrupted, which operations require a maintenance window, and how to stop and recover if an abnormality occurs. Without authorization, do not perform port scanning, password attempts, or fault injection. Even with authorization, start with documentation, configurations, and logs, and place higher-risk verification in an isolated test environment first.
Industrial control systems may be sensitive to latency, packet loss, or connection re-establishment, and the traffic and sessions generated by testing may themselves cause effects. NIST’s OT security guide emphasizes that operation, reliability, and security requirements should be considered together. Therefore, assessment should not only pursue the number of vulnerabilities found; it should also judge the impact of risk on the site, the conditions for handling it, and the recovery method. Do not describe “the scan found no problems” as absolute security.
3. Check management entry points and least privilege
List the actually enabled Web, command-line, Console, and network management services, and verify which sources can access them. Disable unnecessary services, use appropriate secure management protocols according to device support, remove default or shared passwords, and configure necessary permissions for different responsibilities. Remote maintenance entry points should also have approval, authentication, and records, and should not be exposed to the public internet long-term for convenience.
Whether permissions are effective needs to be verified by what a low-privilege account can do and cannot do, and operations should be performed under controlled conditions. Do not assume isolation is already in effect just because role names appear in the interface. The way configurations are saved, the content of backups, and password management should also be checked; backup files may contain sensitive information, so access should be restricted and they should not be placed in a public download location.
4. Zoning controls access; it does not equal encryption
VLANs separate logical Layer 2 broadcast domains and help organize services, but VLANs are not an encryption mechanism and cannot replace cross-zone access control. If devices or upper-layer routing allow intercommunication, ACLs or firewall policies should also be configured according to actual supported capabilities. An ACL is a rule that permits or denies traffic according to conditions; it must specify source, destination, protocol, and direction, not just check a box called “enable security.”
For example, a maintenance computer needs to access the switch management address, but ordinary terminals in the office area do not have this need. In a supported architecture, management sources can be restricted while maintaining the service communication required by the controller. Before changing a policy, list the dependencies first; after the change, separately test that necessary traffic still passes and unnecessary access is denied, and prepare a rollback. Do not directly adopt “deny all,” which can interrupt on-site control.
Address binding, port authentication, and related protection functions also have applicable conditions. A MAC address is not an identity that cannot be forged, and some control devices cannot participate in specific authentication processes. The assessment should record the support and limitations of the function on the current model, and should not assume that a set of abbreviations can cover all threats.
5. Logs and mirroring help make anomalies visible
Logs record logins, configuration changes, and link events, while port statistics reflect changes in traffic and errors. Unified time helps correlate events from different devices; at the same time, check whether logs are saved, whether they can be exported, and whether permissions are controlled. Missing logs do not equal no anomalies; they may mean the function is not enabled, time is inconsistent, or capacity is insufficient.
Port mirroring copies specified traffic to an observation port for analysis devices to view; it does not actively inject attacks into the network. Mirroring should be used within an authorized scope, and collected content may contain sensitive data. If the mirror port and collection device have insufficient capacity, observation data may be lost, so an incomplete packet capture cannot be treated as evidence for the entire network, and it cannot be promised that mirroring will absolutely not affect any load.
6. Firmware and recovery capability are also part of the assessment
Check firmware versions, manufacturer notices, and applicable remediation recommendations, and confirm the source and verification method of upgrade packages. Patches cannot be deployed to production directly without assessment: first confirm configuration compatibility and functional impact, verify in a test environment, then arrange a window, backup, and rollback. Do not directly apply another manufacturer’s vulnerability description to the current device, and do not judge security only by the product release date.
Recovery testing should verify whether backups can be used for the corresponding model, which service parameters need to be reconfirmed after recovery, and how to handle loss of management connection. Clarify responsible persons and available local maintenance methods, so that no one is unable to recover after a configuration error. Service availability, permissions, and log verification should together form the result; a single password check should not be treated as a complete assessment.
The Feichang Technology official website’s managed switch details list Web, CLI, Console, SNMP, logs, port mirroring, and management or security-related functions such as ACL and 802.1X. These can serve as checklist items; they are not a uniform promise for the entire product category, and they do not mean industrial cybersecurity certification has been obtained. The security version, firmware support, and configuration method of specific services must be confirmed according to the delivered model and current manual.
The final record should include findings, evidence, impact, recommendations, verification methods, and residual risk. Investigation ratios whose sources were not clearly stated in the original are no longer used; enclosure protection is also not used as a basis for security scoring. Describe results with reviewable configuration and log evidence, and clearly state the untested scope, so that subsequent maintenance and risk decisions are easier.
References:NIST SP800-82r3 OT Security Guide;Feichang managed switch details. The figures are general principle illustrations, not security certifications, actual tests, or attack guides.
Translated from the Chinese technical article. Source first published: 2022-08-02. Source last revised: 2026-10-13T17:34:48+08:00. Read the Chinese source
