For centuries, security has always had a part to play in protecting our well being and associated environments. But how could we best explain it’s benefits and make technology digestible using history ? One of the important key skills any IT Manager needs to master is the ability to explain technology to senior management. In this article, I’ll try (hopefully not failing miserably) to provide an insight as to how this might work if you used a paradigm. Senior management understand the concept of security, but will not have any idea about the nuts and bolts inside that make up the overall strategy – and quite honestly, don’t care either. In order to understand this from a layman perspective, we need to break down the technical wall and use some history to compare it with. The technical terms have no meaning or value when used in their raw “geek speak” form and the only affect on senior management is either confusion or boredom – but when a mechanism is used where people can relate to what you are explaining, the explanation is much easier. Below, I’ve used all the usual technical buzzwords, but given them alternative meanings that people can easily remember and relate to.
There’s a simple rule to follow here:
Security is your defence from external attack (in simple terms). Now that we know this, let’s look back at some of the features inspired by medieval times. You’ll be surprised at how well this works
In simple terms, consider a medieval kingdom with a castle and an army, whose job it is to protect the king. The fundamental basis of a castle is security. This is the focal point of your topic, and provided you keep this in sight, the rest is relatively straightforward.
Mixing security with the history model
Security is an essential part of any network – as much as a king is to a kingdom, so now we have something to compare the technology to.
Every castle has an external defence. This is typically either a steep hill with the castle built at the top, or for those on level ground, a moat. The moat often served as a food supply, and a way of transporting items around the castle, although it’s primary role was the perimeter defence.
Here we have our first parallel. The perimeter network can be thought of as the moat.
Just inside the castle walls is the keep. This area was primarily used for food storage, and was often 10 feet wide. It served as a mechanism to store various items, and to keep anyone who breached the moat outside of the castle itself. The keep is in fact our DMZ. We allow certain objects in here, but they are not allowed access into the castle itself.
Now what about those arrow slits in the walls that left just enough room for an archer to take aim ? These are the allowed ports and services that can get through the various security measures to reach the inside of our network. Traffic can enter and leave through these narrow points, but from a distance, you’d need to be a good aim to get something through such a narrow gap – think phishing campaigns. Interestingly, these slits are known as loopholes – you’ve undoubtedly heard the term “exploiting a loophole”….
These are your security policies.
What if you want to explain an IDS or IPS system ? What does a castle have to fend off external attack ? Archers on the roof – and if you’re really lucky, medieval soldiers with a cauldron of piping hot oil to pour on you as you attempt to breach the castle walls. This is your Intrusion Detection System, and Intrusion Prevention System explained.
What about “threat actors” ?
Easy. These are the guys on the other side of the moat using large stones fired from a medieval catapult (or trebuchet if you know your history) in an attempt to break down your defence. If the hackers do breach the moat, they will still need a battering ram to break through the castle drawbridge. The problem for the attacker here is that the drawbridge when raised is pressed against the castle walls. Trying to break down this defence would be fruitless. Think of this as a brute force attack on strong encryption.
Unless you can find a weakness in the drawbridge that allows it to drop open, or you can force it open enough to squeeze through, then a hacker’s journey could end here. This can be thought of as a 0Day vulnerability that permits access to a usually heavily fortified system, and nobody has discovered it exists.
If the drawbridge is up, or in some cases, the portcullis is down, we need to prove who we are. This part is your authentication mechanism. Before we are allowed in we have to provide the secret passphrase. In addition, as we want to speak to the king, we have to show our invite. These represent the login details, and the access token for our network. Put them together, and you have a medieval two-factor authentication. What if we pretend to be someone else in order to gain access ? This is impersonation.
Once inside, were are in the courtyard. From a technology perspective, this is the intranet or LAN. From a firewall perspective, it is the inside or trust zone. We are not allowed to roam the grounds unattended, and will need an escort. You can think of this as your permissions structure. If you do not have access, you cannot get in.
Access in this area is much less restricted, but security still applies – using a lesser model. Security uses a similar approach. The term “Outside-In” is applied when describing traffic and policy control (in the Cisco PIX world). You’ve satisfied the security controls from the external perspective, and now you are inside the castle walls, you can do a lot more.
What if our visitor has goods for the king ? Surely, we want to know what is inside this box, package…… wooden horse ? Think of this as your anti virus and malware system. We all know the Trojan horse story from history lessons, and seeing as this has it’s origins in medieval or middle-ages. It fits very well here.
We don’t want surprises, or an unexpected breach of our internal network. That same package could be used to conceal the removal of something from our castle that is valuable. Here is your data leakage policy.
What if our Trojan horse was able to be deployed ? Suddenly, hundreds of soldiers sneak past your security defence and steal various objects of value. Here is your security breach.
The worst that can happen is that the king is kidnapped or killed. This then means the kingdom is under threat, and from the security perspective, this could be seen as the jewel of the crown being compromised. Seeing as this is serious, it becomes your reportable incident. Obviously, we want to know how this happened, so we start our investigation.
After some thorough checking, we now know that the crown jewels were stolen. This is the theft of personally identifiable information. Next, we find that the king has been killed. We need to tell people what has happened.
This is your incident response plan. Provided we are honest in our report, and offer assurance that steps are being taken to fortify the security of the castle, and appoint a new king, then the peasants may not revolt.
You can think of this as your client base remaining loyal throughout. If you told them as soon as possible, they could be on their guard, and take the necessary steps to protect themselves. So what do you do to repair the damage, and stop recurrence ? This is your remediation.
How do I explain remediation ?
After you have a clearer picture of how the attack succeeded, you’ll want to take the necessary steps to ensure that your defences are hardened to prevent something similar happening in the future.
The same can be said for a castle’s defence model, and you can use the same remediation principle on your network.
- If the moat is breached, make it deeper and wider. Introduce some crocodiles !
- If the walls are breached, make them thicker, and coat them with grease so they cannot be climbed
- Add a portcullis after the drawbridge – if the bridge is breached, you still have limited access
- Have your defences tested frequently by an independent “army” – in this case, penetration testers
- Test your incident response plan – you won’t know it works unless you check
So there you have it. Security explained in a manner that people can relate to.
Subtle Hint: you may want to tailor this approach dependant on the audience, otherwise, your senior management could think you’ve lost the plot 🙂
However, you should also remember the below points when sourcing, concept testing, and ultimately pitching your chosen product
- No security mechanism is impenetrable. Castles formed the earliest basis of security, defence and stronghold, and the same applies to your network. You can be breached at any point – you need to be mindful of this at the design stage, and factor in steps to remediation should this become necessary
- There is always something new out there in the wild in terms of a threat, and this could be launched on your defences at any point. No security product is ever going to be perfect
- Ensure your security policies can adapt to change when needed in light of the above
Hopefully, this ride through middle-age history has been a useful experience. It’s difficult to make dull buzzwords fun, but this is a good start 🙂