But how would one get on such "a network" in the first place? I assume it would involve physically opening a (hopefully locked) cabinet in public near the road? So just a bit of cutting/picking reveals an ethernet port, you drop in a wireless bridge, close it back up, and then hack from a parked car?
Running presumably unencrypted SNMP over shared lines is sketchy.
They do have cameras at each intersection, as well as networked audio at many (for all the speakers hanging from light poles that blare annoying instrumental covers of old popular songs).
The shit you saw on NCIS a decade ago and dismissed as "science fiction" is getting ever more to reality.
"LAN" doesn't imply the same use of VLAN trunking or flat network architecture.
Traffic infra being on a VLAN behind the firewall implies a lot of trust in the traffic infra physical plant. You can harden against layer 2 vulnerabilities, but they're a whole 'nother can of worms and possible failure point.
It also implies the possibility of VLAN trunking being used inappropriately.
All the CCIEs I've learned from and trusted were very suspicious about extending the size and scope of LANs offsite through VLANs.
A number of agencies put these controllers directly on the Internet (a search on Shodan for some telltale strings produces concerning numbers of hits).
Others will use one giant flat network across their entire city - so if you get access at once location, you have access to the entire network. This could mean accessing a "rural" or quiet location, but then actually attacking a much busier one.
I don't want to name names for companies in the industry, but you can find them in industry publications like Traffic Technology Today, or often as contributors to the standards documents like NTCIP 1202, ITE ATC 5301, etc.
I will say that there are a number of long-standing (40+ years) companies in the industry that seem to still operate the "legacy" way - slow iterations, very small software team, seemingly not much desire for large change. Basically, a hardware company that also happens to sell software.
There are also newer entrants to the market in the past ~decade or so that operate a lot closer to a modern software company - lots of new features coming out, fast-moving software teams, etc.
(again, all opinions are my own here.)
I was shocked when I learned that NTCIP was built on top of SNMPv1. To make matters worse, there are actually people in the industry against the adoption SNMPv3. That would at least adds a modicum of security via authentication and encryption. I'd prefer we build around another protocol entirely.
Imagine if folks at IBM knew we still used SDLC as the backbone of our communication in the cabinets...
The reality is perhaps even worse than the article suggests. The majority of signal controllers support the NTCIP "standard" MIBs in addition to the "proprietary" MIBs that are provided through FreeTheMIBs. These "standard" MIBs are defined in standards like NTCIP 1202[1], which are freely available online through the NTCIP group.
These standard MIBs let you set/get all kinds of fun settings... put the lights into flash, change timing settings, set "preempts" to give yourself a green light, and more.
The standard also strongly suggests that all vendors use a default SNMP community name of "public". That means, for any traffic controller you happen to find on a network, you can almost certainly change tons of scary settings without even needing to _exploit_ anything!
I've been working in the industry for quite some time, and it's genuinely scary how poorly secured some of this infrastructure is and how slowly things move when issues are found.
(Disclaimer: I work in the industry, not for any of the companies discussed in the article, and all these views are my own and not those of my employer)
[1]: https://www.ntcip.org/file/2019/07/NTCIP-1202v0328A.pdf