Cybersecurity for Small-Department Communications Systems

Why communications systems are now cyber-relevant

Twenty years ago the communications side of a small department was mostly hardware you could touch. A base station, some mobiles, a repeater on a hill, and a paper log. If something broke, you drove to it. The systems in service today still do all of that, but they are wrapped in software and connected to networks in ways that are easy to forget once the install is finished.

Walk through a typical small agency and you will find several places where the communications and IT worlds now overlap:

• The radio core or dispatch console rides on a data network rather than a closed circuit, and that network often shares wiring or switches with office computers.
• Computer-aided dispatch and records management software runs on servers, either in a closet down the hall or hosted by a provider you reach over the internet.
• Station alerting, paging, and fire-house notification tools are increasingly driven by software rather than tone-and-voice alone.
• Staff read email, submit reports, and check schedules on the same machines that touch operational systems.
• Vendors reach in from the outside to update firmware, pull diagnostics, or troubleshoot, which means there is a door to the outside whether or not you think about it.

None of this is a bad thing. These connections are why a two-person overnight crew can be alerted in seconds and why a records request can be answered without digging through a filing cabinet. But every connection is also something that has to be protected. The goal of this article is not to scare you off the technology. It is to help you keep the benefits while closing the doors that should be closed.

Why small agencies are targets, and why they are under-resourced

A common and dangerous assumption in a small department is that no one would bother with us. We are too small, too rural, too boring. In practice the opposite tends to be true. Much of the trouble that reaches small public-safety agencies is not aimed at them by name. It is automated and opportunistic, sweeping across the internet looking for any system that is easy to reach, out of date, or protected by a weak password. A small agency is not too small for that net. It is exactly the kind of thing that net is built to catch.

At the same time, small departments carry a few things that make an interruption especially costly:

• They run around the clock, so downtime is never convenient and there is rarely a quiet window to absorb a disruption.
• They hold sensitive records, from patient care information to personnel files to incident data, that people expect to be handled carefully.
• They depend on a handful of systems working together, so a problem in one place can ripple into dispatch, reporting, and communications at once.

The resource gap is the hard part. Large agencies have dedicated security staff. A small department often has one person who does IT alongside three other jobs, or a friendly local contractor who set things up years ago and has not been back since. That reality is not a reason to give up. It is a reason to focus. The practices below are chosen because they give a small budget the most protection for the least effort, and because a non-specialist can carry them out or clearly hand them to someone who can.

Accounts, passwords, and multi-factor authentication

The single most common way trouble gets into a small agency is not exotic. It is a login. Someone reuses the same password everywhere, that password turns up in a list gathered from an unrelated website, and suddenly a stranger can sign in as if they belonged there. The fixes here are cheap, and they matter more than almost anything else you can do.

Start with the accounts themselves:

• Give every person their own login. Shared accounts where the whole shift signs in as one user make it impossible to know who did what, and they make a password nearly impossible to change safely.
• Use a long, unique password for every system. Length matters more than a jumble of symbols. A phrase of several unrelated words is both stronger and easier to type on a mobile at three in the morning.
• Consider a password manager for the department. It lets each person keep dozens of strong, different passwords without writing them on a sticky note under the keyboard.
• Change any default password that came with a device or software when it was installed. Defaults are public knowledge, and unchanged defaults are one of the most common findings in any review.

Then add multi-factor authentication, often shortened to MFA, wherever the system offers it. MFA means that a password alone is not enough. Signing in also requires a second proof, usually a code from an app on a phone or a physical key. This one step turns a stolen password from a crisis into a nuisance, because the password by itself no longer opens the door. Turn it on for email first, since email is the account used to reset all the others, and then for remote access, dispatch software, and records systems in that order.

Finally, keep a simple record of who has access to what, and review it when someone leaves or changes roles. A departed member whose login still works months later is a loose end that costs nothing to tie off and quite a lot to ignore.

Keeping systems patched and current

Software is never finished. The companies that make your dispatch software, your servers, your radios, and your office computers keep finding and fixing weaknesses, and they release those fixes as updates or patches. An update you have not installed is a known problem left standing. Much of the automated trouble on the internet is looking for exactly that, systems running versions whose weaknesses are already publicly documented and already repaired by the vendor for anyone who bothered to apply the fix.

Staying current does not require you to become an engineer. It requires a habit and a little coordination:

• Turn on automatic updates for office computers and phones where you can. This is the lowest-effort protection available and it covers the machines most people touch every day.
• Keep a plain list of the systems you run and roughly how each one gets updated. Some update themselves, some are updated by a vendor, and some sit untouched unless a person acts. You want no system in that third group by accident.
• Do not let critical operational systems be the exception forever. Radio cores, dispatch consoles, and station alerting often cannot be patched on a whim because a bad update at the wrong moment is its own emergency. That is a reason to schedule updates carefully with your vendor, not a reason to skip them for years.
• Retire equipment and software that the maker no longer supports. When a product reaches the point where the company stops issuing fixes, it stops getting safer and starts getting riskier every month. Budget for replacement before that date, not after.

The theme here is simple. Someone should be able to answer the question, for every system we depend on, when was it last updated and who is responsible for the next one. If no one can answer that, the answer is probably longer ago than anyone would like.

Remote access and network segmentation

Remote access is a genuine convenience. It lets a vendor fix a problem without a service call and lets an administrator check a system from home. It is also, by definition, a way in from the outside, so it deserves more care than almost anything else on this list. The goal is not to eliminate remote access. It is to make sure it is deliberate, limited, and watched.

A few practical principles keep remote access from becoming an open invitation:

• Know every path in. You cannot protect a door you do not know exists. Ask your vendors and your IT contact to list every way someone can reach your systems from outside the building, and keep that list.
• Require strong authentication and MFA on every one of those paths. Remote access protected by a single password is the exact combination that opportunistic trouble is hunting for.
• Limit who can connect and from where. Access should be granted to named people for named reasons, not left open to the whole internet because it was easier to set up that way.
• Log it and glance at the logs. A record of who connected and when is quiet and boring right up until the day you need it, and then it is the difference between knowing what happened and guessing.
• Turn off access that is no longer needed. Temporary access set up for a one-time project has a way of living forever. Close it when the project ends.

Network segmentation is the companion idea, and at the concept level it is intuitive. Not everything on your network needs to talk to everything else. The computers used for email and web browsing do not need a direct path to the radio core. A public guest wireless network in the lobby does not need to touch the dispatch server. Segmentation means keeping those worlds in separate rooms, with a controlled door between them, so a problem that starts on an office laptop does not have a clear run straight into your operational heart. You do not have to design this yourself. You do have to ask your IT resource whether it has been done, because a flat network where every device shares one open space is a design choice that quietly raises the stakes of every other risk on this list.

Backups, phishing awareness, and your people

Two of the most valuable protections a small department has cost almost nothing but attention. The first is a good backup. The second is a workforce that recognizes a trick when it sees one.

Backups are what turn a catastrophe into an inconvenience. If your records, configurations, and important files exist in a safe copy, then losing the originals is a bad day rather than the end of the story. A backup only counts if it meets a few conditions:

• It is automatic, so it happens whether or not anyone remembers.
• It is kept separate from the systems it protects, so that a problem hitting the main system does not also erase the backup. At least one copy should be somewhere the everyday network cannot casually reach or overwrite.
• It has been tested by actually restoring from it. An untested backup is a hope, not a plan. The time to discover that a backup does not work is a routine drill, not the worst morning of the year.

The human side is phishing and social engineering, which is the polite name for tricking a person into opening a door that no software would have opened on its own. It usually arrives as an email or message that looks legitimate and asks the reader to click a link, open an attachment, hand over a password, or approve something urgently. It works because it targets helpfulness and hurry, two traits every good responder has in abundance.

You do not need a training budget to build resistance. You need a short, repeated conversation:

• Slow down on anything urgent that asks for a password, a payment, or a click. Urgency is the most common lever, so urgency itself is a reason to pause.
• Verify through a second channel. If a message appears to come from a chief, a vendor, or a coworker and asks for something unusual, confirm it with a phone call to a number you already know.
• Make it safe to report and safe to be wrong. A member who reports a suspicious message, or who admits they clicked something they should not have, is helping you. Treat it that way, every time, so the next person speaks up too.

Vendor coordination and incident preparedness

Radio infrastructure is the one area where a small department almost never goes it alone, and that is appropriate. Radio cores, consoles, and station alerting are specialized systems, and the companies that supply them carry a large share of the responsibility for keeping them secure. Your job is not to out-engineer them. Your job is to be an informed, engaged customer who asks the right questions and keeps the relationship active.

Good vendor coordination looks like this:

• Know who your points of contact are and how to reach them outside business hours, before you need to.
• Ask, in plain language, how they keep your system updated, how they connect to it remotely, and what they expect from you.
• Ask what they will do, and what they need from you, if something goes wrong. A vendor who cannot answer that clearly is telling you something useful.
• Keep any maintenance or support agreement current, and understand what it covers. Coverage that lapsed three years ago is a surprise best avoided during a crisis.

Incident preparedness is the other half. The worst time to figure out what to do is while it is happening. A small department does not need a thick binder. It needs a short, current plan that answers a few questions any tired crew member could follow in the middle of the night:

• Who do we call first, and what is the number? List your IT contact, your key vendors, and any regional or governmental resource available to you.
• How do we keep running if a system is down? Every operational system should have a known fallback, even if the fallback is paper and a portable radio. Knowing you can revert to a manual process is itself a form of security.
• Who decides, and who do we have to notify? Sensitive records may carry reporting obligations, and it is far better to know that in advance than to discover it later.

Getting help does not have to break a small budget. Many regions have shared resources for public agencies, mutual-aid relationships that can extend to technical support, and partnerships through county or state offices that exist precisely because small agencies cannot each afford a full security staff. Ask your neighboring departments what they use. Ask your regional or state emergency management contacts what is available to agencies your size. A great deal of practical help is free or low cost to those who simply ask, and the asking is the part only you can do.

A starting checklist

None of this has to happen at once. Work down the list at whatever pace you can sustain, and mark real progress rather than chasing perfection.

• Give every person a unique login and retire shared accounts.
• Set long, unique passwords everywhere and change every default that came with a device.
• Turn on multi-factor authentication for email first, then remote access, dispatch, and records.
• Turn on automatic updates where you can, and make a list of how every other system gets patched and by whom.
• Replace or retire any product the maker no longer supports.
• List every path into your systems from outside, protect each with strong authentication, and close the ones you do not need.
• Ask whether your network is segmented so office machines cannot reach operational systems directly.
• Confirm you have automatic backups, kept separate from the main systems, and prove one works by restoring from it.
• Have the phishing conversation regularly, and make reporting a suspicious message quick and blameless.
• Write down your vendor contacts, your first calls in an incident, and your manual fallback for each critical system.
• Ask your region, county, or state what security help is available to agencies your size.

You will not finish this in a week, and you do not need to. Each item you complete makes the next problem smaller and the next bad day shorter. That steady, unglamorous progress is what good security actually looks like in a small department, and it is well within reach of an agency that decides to start.