What the ACSC ISM Says About Network Infrastructure Controls
Network security is often discussed in terms of firewalls, endpoint detection platforms and software vulnerabilities. Those tools matter, but they cannot compensate for an unreliable or poorly controlled network underneath them. A mispatched cable, an unmanaged switch or a failed link can interrupt operations, undermine segmentation and leave defenders with a partial view of what is happening.
The Australian Cyber Security Centre’s Information Security Manual (ACSC ISM) provides guidance for protecting systems and information. It is not a cabling specification or a product-buying list. Rather, it sets out security principles and controls that organisations can apply to their environments. Many of those controls depend on sound network infrastructure: equipment must be configured and managed, access must be controlled, networks must be appropriately separated, and activity must be visible enough to investigate.
That makes network infrastructure controls a practical part of applying the ACSC ISM—not a separate facilities task to be handed off and forgotten. The quality of the physical and logical network directly affects an organisation’s security posture.
Start with the purpose of the ACSC ISM
The ISM is a broad cyber security framework for Australian organisations. Its guidance covers matters such as governance, personnel, systems, applications and networks. Organisations should consult the current ISM and related ACSC guidance to determine which controls apply to their systems, information and risk environment. Requirements may also be shaped by other obligations, including government policy, regulation and contractual commitments.
It is useful to distinguish between what the ISM does and what it does not do. It does not prescribe one universal network diagram, a particular vendor or a single configuration for every organisation. It does, however, set expectations around outcomes such as protecting systems from unauthorised access, managing security configurations, limiting exposure and monitoring for threats. Those outcomes are difficult to achieve if network foundations are weak.
In practice, a secure design has to connect policy to the equipment and work that make cyberdaily.au the network operate. That includes routers, switches, wireless infrastructure, cabling, cabinets, power, management interfaces and the processes used to change them.
Physical infrastructure is part of cybersecurity
A network is not just a logical diagram. It is also copper and fibre cabling, patch panels, cabinets, power supplies and devices installed in offices, comms rooms, plant areas and other locations. Anyone who can access a network port, unplug a connection, attach an unauthorised device or reach a switch console may be able to affect confidentiality, integrity or availability.
Physical security controls help reduce those risks. Depending on the environment, that might mean restricting access to communications rooms, securing cabinets in public or operational areas, keeping equipment inventories current, and documenting where critical links terminate. It also means considering who can access network ports and how unused ports are treated.
Physical and logical controls should work together. A well-configured switch is not much protection if an unauthorised person can reach its reset button or console port. Conversely, a locked cabinet does not make an insecure configuration safe. The aim is to prevent unauthorised access and make legitimate changes traceable.
Make the physical network understandable
Accurate records are a security control because responders need to know what they are looking at. Maintain usable diagrams, device inventories and port records. Label patch panels, cables and equipment in a consistent way. Record which connections support critical services and which devices are approved to be present.
Unlabelled patch panels and “mystery cables” are not merely untidy. They increase the chance that a technician disconnects the wrong service, that an unauthorised connection goes unnoticed, or that an incident response team wastes time tracing a link during an outage. A label maker is less exciting than a new security platform, but it can be considerably more useful at 2am.
When planning new offices or plant deployments, include network and security teams early. Agree on cabinet locations, environmental needs, access arrangements, cable pathways and service ownership. These decisions are harder—and usually more expensive—to fix after the walls are closed and users are waiting for connectivity.
Physical faults can create outages and security blind spots
A damaged fibre, failing power supply or poorly seated patch lead can cause more than a service interruption. Intermittent faults may lead to packet loss, link flaps or unexpected failover behaviour. Monitoring and security tools can then receive incomplete data, lose connectivity or report symptoms that are difficult to distinguish from malicious activity.
That creates a security blind spot. For example, a monitoring sensor connected to the wrong point in the network may see only part of the traffic it is meant to observe. A link failure may silently remove visibility from a segment. A mispatched connection might bypass an intended control or put a device in an unexpected network. If the diagrams and labels are wrong, responders may not realise the monitoring gap exists.
Network observability should therefore be designed, not improvised. Where passive monitoring is required, consider how traffic will be made available to the relevant sensors and how that feed will be checked. Network taps and aggregation tools can support visibility in some designs; vendors such as Garland offer products in this area. Their suitability depends on the architecture, traffic volumes, resilience requirements and operational procedures. A monitoring feed should itself be treated as a service with clear ownership and health checks.
Resilience is also a security concern. Redundant paths, appropriately designed power and documented recovery steps can reduce the impact of a single fault. But redundancy is not automatically protection: if failover is untested, misconfigured or invisible to monitoring, the organisation may discover its limitations during an incident.
Segmentation requires capable switching and correct design
Segmentation is one of the most important ways to limit the spread of compromise. It separates systems or groups of systems so that access can be restricted according to business need. This may involve separate security zones, VLANs, routed boundaries, access-control policies and firewalls. The right design depends on the systems involved and the risk being managed.
Segmentation is not achieved simply by creating VLANs. The network must enforce the intended boundaries, and the rules between segments must be understood and maintained. A design with broad “allow any” access between zones can provide little meaningful separation. Likewise, a flat network where everything shares one broadcast domain makes it harder to contain an incident and can expose services to systems that have no reason to communicate with them.
Switching capability matters. The equipment needs to support the required security features and scale, and administrators need to configure those features consistently. In production environments, unmanaged switches are a particular concern: they limit visibility and control, may introduce unintended connections, and can make it difficult to confirm that segmentation is being enforced. They are not a substitute for managed, inventoried equipment in a security-sensitive design.
Design around systems and trust boundaries
Good segmentation starts with the systems, users and services that need to communicate—not with a desire to create the largest possible number of VLANs. Map traffic flows, identify trust boundaries and document the business reason for permitted connections. Then apply controls at the appropriate points and test that prohibited paths are actually blocked.
For corporate networks, that may mean separating user devices, servers, management interfaces, guest access and sensitive services. For operational technology (OT), the design needs to account for availability, safety, vendor access and the different lifecycles of industrial equipment. A change that is routine in an office network can have operational consequences on a plant floor, so testing and change control matter.
Industrial networking suppliers such as MOXA provide equipment used in OT and industrial environments. As with any vendor, the product is only one part of the control. Organisations still need a defined architecture, secure configuration, access management, asset records, update planning and a process for monitoring and responding to issues.
Secure configuration and administration are network controls
Network devices are systems in their own right. They have software, management interfaces, accounts, configuration files and logs. Treating them as infrastructure that “just works” can leave default credentials, unnecessary services or unreviewed access in place.
Apply a controlled configuration baseline to routers, switches, wireless controllers and other network devices. Remove or change default credentials, restrict management access to authorised users and trusted paths, and disable services that are not required. Keep firmware and software under review, and plan updates in a way that considers operational risk and vendor support.
Administrative access should be limited and attributable. Use individual accounts where supported, apply appropriate authentication, and avoid exposing management interfaces to general user networks or the public internet. Maintain configuration backups and change records so that an approved change can be distinguished from an unexpected one. Periodically review accounts, access paths and rules rather than assuming that yesterday’s access is still appropriate.
Vendors such as Cisco supply a wide range of enterprise networking equipment and security capabilities. The presence of a recognised brand does not, by itself, establish that a network is secure or compliant. Security depends on selecting equipment appropriate to the use case, configuring it well, maintaining it, and operating it in line with organisational requirements.
Monitoring depends on reliable foundations
Firewalls and endpoint detection platforms are important elements of a defensive architecture, but each has limits. Firewalls enforce traffic rules at defined points. Endpoint detection platforms provide visibility and detection on supported endpoints. Neither automatically tells an organisation whether every switch is accounted for, a network link is carrying the traffic expected, or an unauthorised device has appeared in a poorly controlled area.
Network monitoring can help fill those gaps. Collect and review relevant device logs, configuration changes, authentication events and network alerts. Ensure monitoring systems can reach the equipment they depend on, and that the data they receive is useful for investigation. Time synchronisation, sensible naming and accurate asset records make it much easier to correlate events across systems.
Monitoring should also alert on infrastructure health. A security team may need to know when a device stops reporting, a monitoring feed fails, a link changes state or a configuration is altered unexpectedly. The goal is not to generate more alerts for their own sake; it is to detect meaningful changes and know who will respond.
A practical way to assess network infrastructure controls
Use the current ACSC ISM as the source for applicable requirements, then test how those requirements are implemented in the real environment. A practical review can start with the following questions:
- Can the organisation identify its network devices, their locations, owners and purpose?
- Are cabinets, communications rooms and exposed network ports protected appropriately?
- Are cables, patch panels and network diagrams labelled and maintained?
- Are production switches managed, supported and configured to enforce the intended segmentation?
- Are routes between security zones limited to documented business requirements?
- Are device accounts, management interfaces and configuration changes controlled?
- Can the organisation tell when monitoring visibility is lost or a critical link fails?
- Have recovery and failover procedures been tested, including outside business hours?
Build security into the network, not around it
The ACSC ISM should be read as guidance for securing an organisation’s systems and information, not as a checklist that can be satisfied by buying a firewall or deploying endpoint detection platforms. Network infrastructure controls are part of the conditions that allow those tools—and the wider security program—to work effectively.
Solid foundations mean controlled physical access, accurate documentation, capable managed switching, deliberate segmentation, secure device administration and dependable monitoring. They also mean planning for failure: knowing which services depend on a link, how visibility will be restored and who is responsible when something breaks at 2am.
When physical and logical network controls are designed together, organisations improve both resilience and security posture. When they are treated as separate concerns, the gaps tend to appear precisely when time is short and the consequences are highest.