If you want to LISTEN to this Blog, you can do so HERE:
This wraps up my 3-Part series, with a discussion about SECURITY. The MOST important.
BUT, I want to start off by making one thing perfectly clear. This is not a podcast for security specialists. I’m not a security specialist, and don’t profess to be one. This podcast is for the general 911 professional, and is intended to raise awareness in the industry about a very critical issue facing us with the deployment of NG911 across our nation, Public Safety Networks.
When you address YOUR network, engage a CERTIFIED security specialist.
As we recently discussed in recent blogs, GIS data is foundational in modern emergency response… and this is the exact reason that it has become a target.
You see, the moment we started trusting shared maps, third-party floor plans, and “smart building” inputs, we also began to accept a not-so-fun truth: bad data can harm people. This is true whether it’s sloppy, outdated, or intentionally malicious.
GIS data is a target, whether we like it or not
If you thought that my last two blogs were great conversation starters and “here’s why we need it”, this one is the part where I gently take the keys away and say, “OK, cool your jets… FIRST show me your security plan.”
Because now that we’re building richer GIS datasets for NG911with more layers, more attributes, more integrations, more “please send us your building intelligence” partnerships.
Plus, we’re also building something else: A bigger attack surface. And no, I’m not being dramatic. I’m being public-safety practical.
Security cannot be a separate topic from GIS anymore. Security is part of the GIS conversation, whether the map lives in a county GIS office, an ESInet-hosted repository, a vendor platform, or a “helpful” third-party feed that someone swears is totally accurate – and safe. Exercise caution.
Security is ALWAYS an ever-present issue for data.
Public Safety needs to ensure that anything they ingest is safe or sanitized, and that no malicious threat arises from the injection of false or misleading data.
And YES, that’s as serious as it sounds.
Because once we start talking about shared data repositories, third-party data contributions, and “bring your own building intelligence,” we’re also talking about the possibility of:
- outdated or incorrect floorplans during renovations
- malicious alterations to routes or entrances
- spoofed “points of interest” (fake AED locations, fake command posts)
- manipulated hazard data
- data poisoning that causes responders to stage in unsafe locations
- or simply flooding systems with garbage until the REAL data gets buried
If you’ve ever seen a social media map that labels your neighbor’s house as “World’s Best Taco Stand,” you already understand how easy it is for location data to get… creative.
Now replace “taco stand prank” with “emergency routing guidance” and suddenly we’re not laughing anymore.
So let’s talk about how this actually breaks the real world, and what we can do about it.
The uncomfortable truth: GIS is both critical infrastructure and a soft target
In the old days, GIS was “the map.” It lived in a system, was updated when someone remembered, and might get exported occasionally.
In the NG911 world, GIS isn’t just cartography.
- It’s decision support.
- It’s routing and policy.
- It’s where responders go and how fast they get there.
- It’s what they see before they ever step out of the rig.
That means GIS data is now tied to:
- call routing and boundary logic
- response planning and unit staging
- building access and interior orientation
- hazard awareness (gas shutoffs, hazmat rooms, lithium battery storage, etc.)
- school safety and campus complexity
- enterprise and commercial building inputs
- and eventually, more automation and AI-supported “recommendations”
And that is EXCACTLY what makes it worth attacking by the bad guys.
Not because criminals are obsessed with shapefiles… but because criminals, disruptors, and bad guys in general love systems where a small change creates BIG real-world outcomes.
“Bad data” comes in three flavors (BUT only one is accidental)
Let’s simplify the threat landscape without oversimplifying the risk.
FIRST, IS Accidental bad data (WHICH IS THE most common)
This is the innocent stuff: outdated floorplans, a new wall that wasn’t captured, a renamed building, an entrance that became “exit only,” a construction fence that turned a shortcut into a dead end.
Nobody was trying to hurt anyone. But the impact can be the same: confusion, delay, misrouting, and responders walking into the wrong situation.
NEXT COMES Negligent bad data (something more common than we admit)
This is the “we uploaded something because we had to” data. It’s incomplete. It isn’t validated. No one owns it. No one monitors it. The vendor integration is “set it and forget it.”
This is where systems get flooded with junk because the pipeline accepts it, and nobody checks the output until an incident proves it’s wrong.
LASTLY, is malicious bad data (the one we really need to design for)
This is the intentional stuff: poisoning, spoofing, manipulation, denial of service by garbage, and targeted changes that steer responders away from what they need, or toward something dangerous.
If you build a pipeline that accepts external data, assume someone will eventually try to exploit it. Maybe not today. Maybe not tomorrow. But “eventually” is not a comforting timeline in public safety.
What does a GIS attack actually look like?
This isn’t always a hoodie-and-keyboard movie scene. Many GIS compromises are boring, that is, until they aren’t. Here are the real patterns to watch for:
Subtle edits with high impact
- Changing a single entrance attribute from “public” to “staff-only”
- Flipping an access route designation
- Altering a gate location or emergency vehicle access point
- Moving a point of interest by 50 feet (which can be the difference between “front door” and “behind a locked fence”)
The scariest attacks aren’t loud. They’re plausible.
“Helpful” spoofed Pionts if Interest
- Fake AED locations
- Fake incident command post points
- Fake triage locations
- Fake hydrants, Knox boxes, or key access points
These can waste time at best, and endanger responders at worst.
Hazard data manipulation
- Removing hazards that should be visible (chemical storage, high-voltage rooms)
- Adding hazards that trigger unnecessary staging distance or special response protocols
- Mislabeling rooms or floors to create confusion during active events
Data poisoning through volume
Sometimes the attack isn’t “make one thing wrong.” It’s “make everything noisy.”
Flood the system with so many garbage records that:
- the legitimate data is buried
- operators stop trusting the layer
- performance degrades
- humans start ignoring alerts
And once humans start ignoring the map, you’ve already lost.
The core security concept: provenance beats “trust”
In public safety we use the word “trust” way too casually.
“Can we trust that feed?”
“Can we trust that vendor?”
“Can we trust that building data?”
Here’s the better question:
Can we prove where this data came from, who touched it, and whether it changed?
That’s provenance. In a secure GIS pipeline, every meaningful piece of data should have:
- a known source
- a documented owner
- a timestamp (created/updated)
- a change history
- validation results
- and a confidence rating you can defend
If you can’t answer “who supplied this and when,” it doesn’t belong in a mission-critical workflow without quarantine and review.
A practical “Zero Trust” mindset for GIS
(without breaking the mission)
I’ve written and talked before about Zero Trust in 9-1-1 and why it can get complicated. The answer is NOT to turn an ECC or PSAP into a locked vault where nobody can do their job. However, that doesn’t change the fact that the Zero Trust mindset still applies.
Never automatically trust data from external contributions
- Verify structure, content, and intent
- Limit what any one source can change
- Assume credentials will be compromised
- Monitor for weirdness, not just known signatures
This is how you secure a data ecosystem without turning every update into a three-week approval process.
The “secure ingestion pipeline” PSAPs and ESInets need (in plain English)
If you take nothing else from this blog, take this: security belongs at the ingestion point. Not after the fact. Not “when we have time.” Not after an incident proves you were wrong.
Here’s what a modern, defensible pipeline looks like.
1) Quarantine first, publish second
External feeds should not go straight into production layers that dispatchers or responders rely on. They need to go into a staging environment where they can be:
- scanned
- validated
- compared against known baselines
- approved (or auto-approved under strict rules)
2) Schema validation (a fancy way of saying “does this even make sense?”)
That means if a source sends:
- wrong geometry type
- impossible coordinates
- missing required attributes
- fields that don’t match your standard
- values outside allowed ranges
…it should get rejected automatically.
No drama. No debate. Just: “NO SOUP FOR YOU!”.
3) Content validation (because valid format can still be dangerous)
A floorplan can be “perfectly formatted” and still be wrong.
Add checks like:
- does this update conflict with recent verified information?
- does it move critical points too far too fast?
- does it change security-relevant attributes (entrances, access routes, hazards)?
- does it touch protected features that only certain roles can edit?
4) Digital signing and integrity checks
When organizations provide authoritative GIS or building datasets, they should be using mechanisms that support:
- signed payloads
- integrity validation (hashing)
- tamper-evident logs
This isn’t about being fancy. This is about being able to say, “this file wasn’t altered in transit or after submission.”
5) Role-based access control for edits
Not everyone should be able to edit everything. Your system needs to support capabi;lities such as :
- limited roles (view vs propose vs approve vs publish)
- separation of duties (the person who uploads is not the person who approves)
- protected layers for critical features (boundaries, routing layers, primary access points)
6) Rate limiting and anti-flood controls
If a feed starts firing 50,000 updates in an hour, that’s not “helpful.”
That’s either:
- misconfiguration
- corruption
- or an attack
Either way, it should trigger throttling and alerts.
7) Monitoring and anomaly detection (the “this feels weird” layer)
Look for:
- spikes in edits from a single source
- edits happening at unusual hours
- repeated changes to the same features
- sudden shifts in geometry
- new Points of Interest with suspicious naming patterns
- “impossible” building attributes that don’t match known reality
You don’t need Hollywood AI. We’re talking about common sense and basic guardrails along with some relevant alerting rules.
Reality check: dispatchers can’t be forensic analysts
Well, you CAN BE THAT. But that’s a different job entirely. The goal here is not to dump more responsibility on PSAP staff. The goal is to build systems where:
- the data is trustworthy before it arrives
- suspicious updates get caught upstream
- operators have confidence indicators (“verified,” “unverified,” “stale,” “pending review”)
- and critical response decisions are not made off “whatever showed up in the layer today”
In other words: humans should be empowered by data, but not forced to babysit yet another system.
The bottom line: secure GIS isn’t optional in NG911
GIS data is a target. Not because maps are trendy, but because maps move people, and in public safety, that movement has consequences.
If we’re going to build the next generation of NG911 data sharing where floorplans, hazards, access routes, and points of interest become part of routine response, and then security has to be baked in as a first-class requirement:
- provenance
- validation
- quarantine
- controlled publishing
- monitoring
- governance
- and rapid rollback
If we do it right, GIS becomes a force multiplier: faster response, better decisions, safer outcomes.
If we do it wrong… we get “World’s Best Taco Stand” energy in the middle of a life-or-death call.