security, soft shell no more

Last time we talked about the hard shell, soft interior model of information security with the conclusion that having a hard shell is no longer necessarily good enough for modern networks. This post is going to focus on some of the things we can do about that (the same warnings from last time apply. This field is vast and I am certainly not an expert in it).

soft interior no more

Imagine the following scenarios:

SSH into one of the hosts that are running your infrastructure, then from it SSH into another host and from there to another

Connect into one of your systems that doesn’t need mongo as part of debugging an issue. You realise that you want to check some data from the DB so from there you make a call to mongo to get them

One of the other users can’t connect to a particular host so you connect into that host and on the fly you edit their permissions to give them access

Now, imagine that in all of those situations the actor was not you, but an intruder that managed to compromise one of your systems.

This kind of openness—soft shell—means that a compromise of a single system can immediately snowball into dozens of other systems. It’s a particularly pernicious kind of compromise because it can start in a non-critical system that receives less love and attention during security reviews and after a few hops end up on sensitive, critical systems.

little walled gardens

Of course what I am talking about here is the principle of least privilege which we have talked about before. The concept behind it is simple. Every system, layer and script should only have those permissions it needs to do its job and only those permissions. If a server does not need db access then it should not have it, a process should not run as the root user if it does not absolutely need root privileges and a service should not be able to talk to an API it does not need.

This kind of isolation is effectively about keeping small mistakes from having serious consequences. If an intruder were to gain access to a system, but is then stuck in the confines of that system and its direct dependencies the damage they can do will be minimised compared to if they can convert that intrusion into unfettered access.

This post should provide a starting point into some good practices for securing the interior of a network, but I would urge you to follow this up with additional research. The principle of least privilege is an important practice, but it’s not the only one that applies here.

If you enjoyed the read, drop us a comment below or share the article, follow us on Twitter or subscribe to our #MetaBeers newsletter. Before you go, grab a PDF of the article, and let us know if it’s time we worked together.