The perimeter is a lie (part 1)

The perimeter is a lie

I recall in early 2000’s having a debate with a security expert about firewalls, at the time they were advocating the firewall model was fundamentally broken! Their argument was that if any traffic could get through, in any direction, for any purpose, bad guys could figure out how to use it to exploit the system. I disagreed, believing the ‘new’ filtering technology would be able to stop them; I was wrong.

The myth of the perimeter still persists today – we see it again and again in security technology such as sandboxes, containers, virtual machines and of course firewalls. All of them seek to secure systems by putting a boundary around them and stopping bad things happening. This is an very attractive idea, and goes back to real world defensive strategies that have worked for centuries – castle & town walls have been very effective at protecting their inhabitants.

In IT systems there is one big difference: our walls are full of holes because we open up holes to let through ‘good’ traffic. In the castle analogy this is like guards (firewalls, sandboxes etc) on the gates & walls to make sure that only what we want can go past. But unlike in the situation at the castle, in the complex world of IT it’s incredibly difficult to tell what is bad traffic. In ancient times you just had to look for people with swords (and the occasional Trojan horse) – but with data traffic, telling the difference between bad & good traffic is impossible (especially if it’s encrypted).

This goes to the root of system design – far too many IT systems rely on a perimeter and a ‘safe’ zone where you ‘trust’ the network and data on it. This does not work. The reasons are many; and here are some of them:

  • Programming mistakes happen – there is no way, practically, to ensure they don’t – so even ‘harmless’ data can trigger harmful consequences. ‘Input Validation’ has been been on the top 10 list of attacks from OWASP since it began and it isn’t going anywhere!
  • People can’t always be trusted – your staff need access to systems, but sometimes they will, due to malice, incompetence or simply corner cutting, expose the system behind the perimeter.
    It’s really complex to actually secure any computer – if you’ve ever done any of the following, your computer _may_ be compromised:

    • Installed software from the internet
    • Opened a document with macro’s and let them run
    • Failed to patch it the same day patches have come out
    • Run any piece of software with a vulnerability
    • Plugged in any USB/Displayport device

Once a bad guy gets behind the perimeter in most IT systems their job becomes really easy – they generally can start installing things, running malware and extracting data. Many organisations have ‘smart’ logging systems to help monitor for such activity. However much of the time they are ignored; they tend to generate a lot of false positives, and a smart intruder could defeat them.

This is especially true for IoT – in IoT we’re seeing a huge number of devices running on the ‘home’ network behind the ‘firewall’ that assume perimeters can protect them. Let’s take some examples:

Example 1: If your device has ‘outbound’ access only, this does not protect you; attackers can use the App to reach through your firewall via 2 main methods:

  • MITM (Man-in-the-Middle) the connection and modify the data
  • Tampering with your app and making it send malicious data. Most API’s forwarding from apps to devices don’t have enough input sanitation to prevent this.

Example 2: If your device listens on the internet (often via UPNP) it’s directly exposed; many devices don’t have:

  • Strong passwords
  • Rotatable passwords
  • Strong authentication protocols with anti-replay
  • Repeat failure blocking
  • Enough input validation on login to prevent exploits
  • DOS protection
  • Encryption

Example 3: If your device talks to other devices on the local network it’s indirectly exposed, but is just as vulnerable as one on the internet, unless:

  • Your device has all of the above for internal network
  • AND every single device on the network is secure

So what’s the solution? On one level it’s simple: shrink the perimeter to the smallest possible size. In practical terms this means you should ensure security at Application / Container/ MicroService level:

  • Each App/Device should have direct authentication/encryption
    • This is a challenge for TLS offload – but if used you need to make sure the un-encrypted segment is as small as possible
  • Each App/Device should have local network access control blocking all traffic it does not need (both inbound and outbound!)
  • Each App/Device should be read-only except for what actually needs to be writable
  • Each App/Device should be signed and verified ideally at boot and runtime
  • App/Devices should all authenticate to each other using unique, rotatable and regularly rotated credentials
  • Logs should be centralised and tuned to provide useful and actionable data


This is all stuff that is possible today; it’s rarely properly implemented, but it’s possible. In a subsequent posts I’ll discuss how we can achieve all of this.

One thought on “The perimeter is a lie (part 1)

Comments are closed.