Our small law-enforcement agency is moving to a self-hosted dispatch and records-management system running on Windows Server. Its mobile app needs to connect to the server, which appears to require an inbound firewall port. The phones use dynamic WAN addresses, so we cannot simply allowlist their source IPs.
When we asked the vendor about the security model, they said the connection uses an encrypted, signed SSL certificate, the endpoint is a web service, and access requires Active Directory authentication plus membership in a specific AD security group. Their main reassurance was that the product is installed in many organizations and they have never had a problem.
That answer feels incomplete. Does this provide meaningful protection, or would the web service and login endpoint still be exposed to internet scanning, password attacks, and vulnerabilities in the application or server? What should we require regarding MFA, TLS, certificate-based authentication, patching, vulnerability management, network segmentation, logging, and compliance requirements such as CJIS? A VPN or zero-trust access solution is possible, but it would add steps for users accessing the system from their phones.
5 Answers
If a direct internet connection is unavoidable, treat the server as a high-risk public-facing service: isolate it in a DMZ, restrict its access to only the systems and ports it genuinely needs, prevent unnecessary access to the internal network, keep the operating system and application patched, monitor logs, scan the external attack surface, and have tested backups and an incident-response plan. AD authentication alone does not protect against a pre-authentication vulnerability in the web service.
I would avoid placing the application server directly on the public internet. Put it behind a VPN or zero-trust access layer, preferably with managed devices, MFA, and device-based identity. That lets you close inbound firewall ports instead of relying only on the application's login screen. For a small number of phone users, the additional support burden is probably much cheaper than dealing with a compromised server or records database.
A VPN is not the only possible design, but some form of pre-authentication or private overlay is preferable to exposing the application directly. An outbound connector or zero-trust gateway can sometimes avoid inbound firewall rules, though compatibility depends on whether the mobile app supports browser-based identity, service tokens, or client certificates.
The wording about an 'encrypted SSL certificate' is imprecise and should prompt more questions. They should be able to explain whether they mean modern TLS, server certificate validation, mutual TLS, or merely HTTPS. Have someone technically qualified review the design and verify it against your agency's security and regulatory requirements before deployment.
The certificate protects the connection in transit; it does not automatically make the exposed web application safe. Unless the design uses mutual TLS or another strong device-authentication method, the internet can still reach the web listener and attempt to exploit vulnerabilities or attack the authentication endpoint. Ask exactly how the phone, user, and AD authenticate, whether MFA is supported, what protocol is used, how accounts are protected from password spraying, and how quickly the vendor patches and responds to vulnerabilities.
Also determine whether this system stores or can reach criminal-justice information. The applicable security policy may require MFA and additional controls for remote access, regardless of what the vendor normally deploys.
Ask the vendor for a current architecture and data-flow diagram, supported authentication details, patch and vulnerability-management commitments, penetration-test or assessment results, and a software bill of materials. A vague claim that many customers use it is not a security evaluation.