Protecting internet-facing services on public service CNI

If you've always used an online service to conduct a function, ask yourself if it's still required today. As discussed in the NCSC's Import Data, Not Malware blog, it's healthy to continually challenge your thinking, and to ask what precisely is the purpose your internet-facing service?

Do you need to operate an internet-facing service 24 hours a day, if you only accept data via that service once a week? Do you need to have the service operating all the time? In short, if you don't need it, turn it off. Similarly, some services will offer optional ports that are enabled 'out of the box' with standard credentials, but with functionality that you may not need. You should always seek to disable optional ports and internet-facing functionality that you aren’t using.

Legacy services are often cited as the initial route of compromise, as they are more likely to be forgotten about (and go unpatched). This is one example of why it's important to establish and maintain authoritative information about your assets.

So you've confirmed the need to host and operate an internet-facing service. The next step is to identify your users, and how they interact with the service.

Your online service should have robust authentication and authorisation wherever possible. A simple way to achieve this is to implement multi-factor authentication (MFA) for your legitimate users. Anonymous access should be enabled only where absolutely necessary.

If your internet-facing service provides privileged operations (such as management or configuration), you should ensure this is from a trusted device (as detailed in the NCSC's Secure system administration guidance). The guidance helps organisations move from an unsafe ‘browse-up’ for administration model, towards privileged access management (PAM). And although it's still an emerging practice within public sector CNI, adopting a zero-trust architecture could help an organisation to meet its CAF objective of Identity and Access Control.

You should expect your internet-facing service to be impacted by either planned or unplanned events. Even if the service is neither attacked nor fails, it will need to be updated and maintained at some point, which means taking the service down. Is this tolerable for your business? These scenarios are covered in the NCSC's cyber security design principles (specifically Reduce the impact of compromise and Make disruption difficult), although all the principles are relevant to public sector organisations.

You should also consider where services are served from. Your first choice may be to host them within a localised DMZ alongside some other critical services. However, you may want to segregate those exposed services in their own network in order provide further defence-in-depth. In fact, hosting it outside your own enterprise boundary (i.e. using a cloud provider) could reduce the opportunity for an attacker to pivot and degrade other critical services.

Gaining assurance is rooted in your confidence in the service's supporting capabilities, such as logging tools and application monitoring. In a different blog, the NCSC describe what exactly an organisation should be logging. Any internet-facing service should be capable of capturing events for logging purposes, regardless of whether they are from user interaction, or interactions from other systems. Attackers will seek to exploit public-facing internet services, so make sure you know what you are logging, and how you can respond (in line with the secure design principle Make compromise detection easier).

Confidence can also be gained in periodically assessing your internet-facing service with external tools that detect common configuration errors. Tools like the NCSC's Web Check and NCSC's Early Warning Service can provide automated reporting of potential issues that you can remediate before potential issues arise.

Ultimately, the best way to ensure a high-level of confidence in an internet-facing service is to ensure your defences evolve with emerging security threats and vulnerabilities. Security is not a 'set and forget' exercise. Attackers don't sit still, so neither should you.

As a security specialist, I get to workshop bespoke architectures over a whiteboard and coffee. Sadly, it's not possible for me to provide tailored architectural advice to every reader of this blog, but I can share some essential concepts that the NCSC often recommend.

• Boundary controls. Intrusion Detection Systems (IDS) and Intrusion Prevention Systems (IPS) can provide more benefits than a stateless firewall. However, they are only as good as the rules they're instructed to follow. You may also need someone to interpret the logs, and investigate appropriately.
• Handling untrusted data. In some cases, the impact of compromise from external (and potentially untrustworthy) data is too great a risk to accept. In such cases, we would advocate for the adoption of the NCSC's cross-domain principles. This would still allow the flow of necessary information, but would minimise the opportunity for cyber attackers to abuse the service.
• Beware the anti-pattern. What initially appears to be a logical design may end up as one (or more) of the NCSC's Architectural Anti-Patterns.
• Documentation, documentation, documentation. While this does not directly add a layer of defence to your architecture, it does massively help people get up to speed with your systems. An indicator of good documentation is how accessible it is to read; even complex systems can presented in a easily digestible way (as hopefully this blog illustrates). The NCSC blog on how to draw good architecture diagrams provides some tips (and common pitfalls to avoid).