FirstNet’s Security and Privacy Considerations
Wednesday, July 24, 2013 | Comments

When viewed through the lens of common citizens who might benefit in a crisis from a first responder’s contact with emergency services, the First Responder Network Authority (FirstNet) initiative is a no-brainer. The speed at which first responders can communicate, collaborate and direct activities designed to rescue or protect the populace during a natural or man-made disaster will often mean the difference between catastrophe and survival itself. The raison d’etre of FirstNet is availability, designed for overlapping redundancy to ensure that first responders can constantly verbally or digitally cooperate in a crisis.

However, from the information security and privacy standpoint, an assurance of availability often is at the direct compromise of a system’s integrity and confidentiality. The more forgiving a communications system in terms of access, the more difficult it becomes to validate that users and traffic traversing the system are authorized to use the resources provided, and free from harm to other users or system devices.

The age of Internet-enabled devices created a stampede of new connections that produce unbelievable productivity and collaboration gains. Unfortunately, it also comes with a much larger surface area for information security and privacy practitioners to cover with the same (or less) budget and a finite number of trained resources. With respect to FirstNet, the problem can be summed up at a high level:

• How can FirstNet aggregate bandwidth be protected to ensure that crisis-related traffic remains fully available? A compromise of a carrier or Internet-enabled device that begins a large consumption of bandwidth for non-crisis activities could put people’s lives in danger.

• How can practitioners provide authorized access to first responders and not impede crisis-related activities while ensuring that the traffic (voice, text and data) traversing the network is free from harm? A compromise of a device that propagates malware onto FirstNet during a crisis could have a direct, negative impact on successful crisis resolution. Further, once the crisis is resolved, the same FirstNet that was used to save lives could be used to compromise the privacy of survivors.

• FirstNet consumers need to connect to Internet-enabled national resources, such as the FBI National Crime Information Center (NCIC) or more regional resources — local emergency services or the Arizona Criminal Justice Information System, for example. Security practitioners need to ensure that they aren’t allowing FirstNet consumers or devices to be the vector for attacks against those resources.

• Lastly, protection, detection, auditing, reporting and remediation of issues discovered on FirstNet must be provided without creating disruption, particularly during a crisis, regardless of whether the issue stems from a FirstNet consumer who has either been unknowingly compromised or is a purposeful attacker.

Like many complex, interconnected systems, the FirstNet security and privacy challenge is a difficult one. However, making a few considerations during the network design phase can help foster an environment of availability without unduly compromising confidentiality and integrity. This list is by no means complete, but will lend itself to incorporating security into the FirstNet foundation.

Hardware Asset Management — Much like the Department of Homeland Security (DHS) recommendations for continuous diagnostic monitoring, hardware asset management is a good place to start. The crisis nature of FirstNet traffic would preclude simply stopping a small number of unknown devices from gaining access to the network. However, the larger number of devices would be identifiable, seen consistently and could have policies created based on the role of the device’s user. This gives practitioners a method for measuring predictable and outlying behavior for known devices, and a method for potentially isolating and treating an unknown device with a greater level of inspection, logging and forensics.

Protocol and Application Enforcement — The methods that Internet-enabled devices use to communicate are extremely porous, based on communications methods called protocols that were designed in the early 1990s. For instance, although most people associate the HTTP protocol with their web browser, the loose nature of the protocol typically will permit just about any other type of traffic to “ride” over it — peer to peer, voice, file transfer, instant messaging and an endless variety of other vectors for potential attack. Performing protocol and application enforcement will allow FirstNet security practitioners to separate the wheat from the chaff — ensure FirstNet crisis traffic while preventing misuse or attack. For instance, the use of instant messaging between two first responders to coordinate rescue efforts is what FirstNet is all about. But using instant messaging to share the latest Top 40 music hits is patently irresponsible and should be prevented.

Security Criteria — The organizations with data that FirstNet consumers will need, such as the FBI and state agencies, must work collaboratively with FirstNet architects to proactively establish common criteria that can be checked and enforced before their resources can be used by FirstNet subscribers. This will ensure that only authorized users are performing permitted activities. The kinds of things that must be ensured include but are not limited to:

• User credentials — Who are you and how do we prove it?

• User role — Does what you do in a FirstNet capacity give you rights to use this FirstNet resource and to what extent?

• Resource protection — Is what you’re putting into the resource free of malware? Does your role give you rights to put it where you’re trying to?

• Data protection — Are you copying sensitive data outside of a FirstNet resource? To where and for what FirstNet supported purpose?

FirstNet can be a fantastic resource that assists the populace during the kinds of events where they need it the most. By ensuring that information security and privacy are a foundational part of the design rather than being bolted on after the fact, the users, security practitioners, and most importantly, the public can have their cake and eat it too.


Scott Montgomery is vice president public sector solutions for McAfee. He has been with McAfee since 2008. Prior to the acquisition by McAfee, Montgomery ran worldwide product management and corporate strategy for Secure Computing, designing and building products.

Your comments are welcome, click here.


Post a comment
Name: *
Email: *
Title: *
Comment: *


No Comments Submitted Yet

Be the first by using the form above to submit a comment!

Magazines in Print

May 2019

1 - 2
Comms Connect
Auckland, New Zealand

5 - 10
APCO Western Regional Conference 2019
Scottsdale, Arizona

More Events >

Site Navigation