In the writing trade, knowing where to begin is sometimes half the battle. When it comes to app ecosystems, however, where better to start than FirstNet, a public-private partnership between the US government’s First Responder Network Authority and AT&T. FirstNet now has more than 24 apps in its app catalogue (known more formally as the FirstNet App Catalog). These include Explorer for ArcGIS – a mapping app and data viewer that allows first-responders to create, mark up and interact with their maps, even when offline, and Intrepid Response, a situational awareness solution that provides near real-time location data on a feature-rich map, along with rapid media sharing. The catalogue also bundles complementary apps together.
Mark Golaszewski, director of applications at First Responder Network Authority, says the current crop of apps is “great early life progress but we want to continue to build upon that”. However, he adds that one area where “reality has challenged us to take a closer look has been in some of the mechanics of the programme”, giving the decision to take the responsibility (and associated cost) for scanning candidate apps from the developers as an example. While FirstNet still has two categories for the apps in its catalogue, one of them has been renamed from Reviewed to Listed to indicate this change of approach.
Golaszewski says “we found the requirement for security scans sets a pretty high bar in terms of integrity and security of the software – that was a portion of software development methodology that wasn’t necessarily a best practice followed by all software developers. We’re providing that security scan on behalf of developers and working with them should any vulnerabilities be identified.”
The other category is Certified. Apps that fit this category have to fulfil the same requirements as their Listed counterparts (being relevant to public safety users and having the appropriate security and data protection measures), while also having to meet certain availability, resiliency and scalable requirements. Golaszewski adds that an app designed to act as a convenient alternative to heavy reference manuals listing the procedures for handling hazardous materials is an example of an app that would be Listed, while a situational awareness app, where a user would need to be “highly confident” it will be available when they have to deal with an event, would be a better fit for Certified certification.
Golaszewski says “we have a public safety app developer programme, so we’re continually looking to improve and streamline the processes. We’re looking to have a rich and diverse portfolio of solutions, so how best to do that while keeping the standards high is something we’re continuing [to look at].”
He says FirstNet has “had enquiries from some public safety agencies who [believe] their solution might have wider applicability [beyond] their day-to-day operations”, in that other agencies might benefit from it as well.
One obvious challenge for FirstNet and other public safety organisations seeking to grow their own app ecosystems is the difference app developers might experience in terms of the time they start seeing a return on their investment in public safety compared with, say, the next Candy Crush or Pokémon Go.
Golaszewski says this can partly be addressed through the organisation’s conversations with its counterparts and partners in other countries, and exploring whether the app addresses something “unique to public safety in the US or might have more global applicability”.
Security matters
Returning to app security, enter the National Institute of Standards and Technology (NIST)’s Public Safety Communications Research (PSCR) division. John Beltz, its IT security manager, says “most of the apps that you load onto your [personal] phone are known to have vulnerabilities. An overwhelming majority of apps are not properly secured [and] those sort of vulnerabilities would be problematic for public safety [use].”
He adds that PSCR is looking at the industry as a whole and testing all the application vetting services that are available with a library of mobile applications with known vulnerabilities. Through doing so, it is possible to determine which of them spots the most vulnerabilities and how each service reports them.
“It’s extremely variable, all the application vetting services are finding different things,” Beltz says. “They’re not reporting them consistently, so basically it needs improvement.”
That said, he adds FirstNet’s system is “on par or better than what we’ve seen from the industry as a whole”, and its application vetting services are proprietary within AT&T and there is no application vetting service that was specifically built for FirstNet or public safety. “They’re using commercial tools, we’re using commercial tools.”
Beltz says public safety agencies should be aware of potential vulnerabilities and “know that they need to apply every single patch as it becomes available”. He adds that “when you start talking about how we’re going to fix this, it’s a much larger problem than the public safety community”, noting the millions of apps available on commercial app stores. PSCR is raising awareness and “probably providing some additional tools to the public safety community to help make their security decisions [when] they’re using these services”.
Beltz says PSCR and FirstNet collaborate on a monthly basis on the subject of mobile security, so it knows all the results “in real time”.
A question of trust
PSCR’s other research track is focused on interoperability and secure authentication – both of which take on more significance in a world in which first-responders are accessing databases with apps on their mobile devices. There is also the ‘Tower of Babel’ in the US that has been inadvertently created by the proliferation of small local LMR public safety networks – an issue that FirstNet was founded to address.
Beltz says there needs to be a secure way to create interoperability and maintain proper access controls. “Just because you’re on the same network doesn’t mean you want to share your sensitive data with every other user. So we started off our research in looking at [how to manage] that through Federated ICAM (Identity, Credential and Access Management) [and] federated identity.”
He explains that PSCR and the National Cybersecurity Center of Excellence (NCCoE) have created a mobile single sign-on solution, which is at the pilot/demonstration stage, that allows users to “log on securely using FIDO – fast identity online; you log on one time to one application on your mobile device and then any app that is within that ecosystem you can then open securely and automatically”.
The system uses commercially available non-proprietary technology and “we have a practice guide that’s out… that shows any public safety agency how to replicate [it]”.
He adds that this is for data and applications only at this point. In the event of a mutual aid scenario, the agencies involved would have been registered with the same federation of identities – “basically a central proof of trust. All participating agencies register to this trusted service, enabling them to trust each other’s accounts. That’s a quick definition of what a federation is – it’s a trust framework that now your local agency account, which is probably Microsoft Active Directory, can trust another agency instead of having to create an account on your system for somebody to access your resources. They can use their own agency account, which is probably also Microsoft Active Directory, allowing for secure interoperability.”
Beltz considers the PSCR’s work around mobile single sign-on and Federated ICAM to be so important – and “there’s so much work to be done” – that he has decided that “our research portfolio is going to focus for the next four years on that subject”.
He adds that while the technology is there and the concepts around federation and trust frameworks are understood, there are a lot of hurdles that PSCR is trying to overcome. For example, there are multiple ways of handling federated identity (which are in use by federal and state governments and by industry), “but they’re kind of disparate, there’s different protocols you can use, there’s different back-end authentication solutions, [and] FIDO is a constant state of development”.
Because of the above, getting all the 60,000 public safety agencies in the US to decide on one technology or finding a way to make “those different technologies interoperable within the same architecture” are formidable political and technical challenges.
“We’re setting up a demonstration architecture with our partner the NCCoE – we’re going to be doing a lot of innovation in that space. I’m also involved in several work groups that are doing work in this area. There’s one option called SAFECOM/NCSWIC that’s defining a trustmark framework specifically for public safety. This has been endorsed by many public safety advocacy groups,” Beltz says.
What about blockchain? Beltz adds that in the public safety community, he is seeing a lot of movement in that direction “for recordkeeping for ledgers, police and medical reports, things like that. From the identity management space, there could be implications, but it hasn’t really been a heavy topic at this point. Blockchain and all of the available Federated ICAM technologies, they’re not suited for playing well for each other right now. It’s possible in the future, but right now there’s no work being done in that area.”
But what of voice? FirstNet’s Golaszewski notes that PTT apps were used by first-responders during the Boston Marathon this spring, and during the response to the recent hurricanes in lieu of LMR radios, where their supporting radio infrastructure had been taken offline and deployable LTE solutions were used to provide coverage. He explains: “There are PTT solutions that are available today but they are not yet based on MCPTT standards as set by 3GPP, but it is outlined in our contract with AT&T that as a feature of the FirstNet solution, mission-critical PTT will have initial availability currently targeting 2020. So devices, accessories, interoperability with LMR, application programming interfaces and integration with public safety apps and support services are all important to achieve PTT but, ultimately, this is public safety’s network and they’re driving this market, so they will decide when PTT delivered via LTE is proven secure, reliable and available enough to meet their needs.”
Golaszewski says how public safety agencies will interoperate using MCPTT devices is still being discussed by the standards-making bodies. “There are basic group management capabilities that are codified in the standards right now, but that’s still evolving to make it more flexible across agencies.” He also sees the development of an interworking function between LTE and LMR (which is also in progress) as critical to the success of MCPTT.
Opening it up
One of the initiatives that is working to support the MCPTT ecosystem is the Mission Critical Open Platform (MCOP) project. The platform will include different levels of API, the Android-based Open Source implementation of a MCPTT client, a demo application and a live online platform in which researchers, developers and other practitioners can test, evaluate and validate their MCPTT-compliant applications. The project is led by Spain’s University of the Basque Country, together with TCCA, Expway, Bittium and supported by Nemergent.
Harald Ludwig, chair of TCCA Technical Forum, says device manufacturers will benefit from implementing the MCOP API because they will have “greater visibility” and probably “more interest from application developers, because if application developers are using the MCOP API, they can be sure their application will work on any of the devices supporting the API, they don’t have to adapt for individual devices”.
He adds: “Almost every device manufacturer visited our stand at Critical Communications World and we received some quite promising feedback. The interest at the PSCR Stakeholder Meeting was similarly high. There’s interest from everybody; the question is, are the manufacturers going to implement the API on
the devices?”
MCOP’s stands at CCW and a PSCR Stakeholder Meeting proved to be popular with device manufacturers
Ludwig hopes user organisations will request MCOP API integration from device manufacturers and notes they have more incentive to ask for its adoption given that it will enable greater interoperability and reduced potential for vendor lock-in.
He says part of the thinking behind the MCOP is to try and move the industry away from closed ecosystems. “There’s a few device vendors on the market now and [many of them are] trying to grow their own ecosystems; they all do their hackathons and try to get application developers interested, but these are closed systems. What we’re trying to do with MCOP is to open this up so there’s really interoperability between devices and applications, thus making the ecosystem bigger for everyone.”
Ludwig adds that the MCOP project is discussing its work with FirstNet and AT&T. “The issue is that the MCOP API itself is not really an application, so it doesn’t fit into the FirstNet App Catalog, but we hope we will find a way to make MCOP also available in the FirstNet app store as we think this would help FirstNet to grow its ecosystem and get more application developers interested.”
From what we’ve heard, there are clear parallels between the world of public safety apps and the devices they rely on. Just as public safety has embraced the wider telecoms market to increase the economies of scale that can be achieved on the device and infrastructure side, there are strong incentives for user organisations, operators and manufacturers to all work together to grow the global public safety app ecosystem.
