by Phil Martin
Monitoring
Towers, called turrets, were often constructed on top of walls to provide greater visibility into the distance, allowing the defenders to keep tabs on the various activities an attacking force might be up to. Keeping the surrounding countryside clear of obstacles such as trees was crucial for this type of activity. If two concentric walls were built to the same height, then soldiers manning the inner wall were pretty much useless until the outer wall was breached. Castle designers recognized this, and to achieve maximum efficiency they would often build the outer wall at a shorter height than the inner wall. This allowed inner archers to shoot arrows just above the heads of the outer wall and into the attacking army. Even more important, though, was the ability for soldiers on the inner wall to monitor the attackers without fear of being hit by incoming fire – their line of site remained unobstructed but were out of reach from the attacker’s arrows, as shown in Figure 10.
Figure 10: Monitoring in the Middle Ages
This medieval activity is an excellent analogy for modern monitoring. Monitoring is the activity of both watching events in real-time and recording that activity for later analysis. There are three types of monitoring we can carry out - logging, IDS and IPS. Logging is the act of simply recording events in some type of persisted repository – usually a file, but it could also be a database that is optimized for write operations. Logs should be periodically reviewed for suspicious activity. While this type of activity is more of an after-the-fact security control, an intrusion detection system, or IDS, watches events and generates alerts in real-time when something happens that matches a pre-defined pattern, much as a turret sentry might do. For example, an IDS can watch packets passing by and inspect the contents. If it detects packets that look like a virus, it can generate an alert to administrative personnel. This is akin to wall-based soldiers intently watching the enemy to detect huddles of soldiers appearing to be constructing something. If detected, the soldier would alert the castle commander that the enemy might be constructing a catapult, and archers could concentrate their fire on this mass of industrious attackers. Of course, actively returning fire is more than an IDS would do – it simply generates an alert. On the other hand, an intrusion prevention system, or IPS, is essentially a weaponized IDS that takes such action when a threat is discovered. Think of a wall soldier who sees this mass of activity and starts firing arrows immediately because he has received prior instructions to do just that – this is an IPS. Most IPSs would simply direct additional soldiers to the wall section that will soon come under fire, essentially shoring up defenses, but in the most extreme cases an IPS will fire the digital equivalent of arrows and even stones at an attacker. See Figure 11.
Figure 11: IDS and IPS
Another use of a medieval IDS would be to listen to the ground for signs of digging. Attackers would often try and go under a wall and popup inside of the courtyard, and the only way to detect where a tunnel would appear would be to intently listen for sounds of digging. Whereas an IDS might simply report the location of digging, a IPS would dig a tunnel to meet the attacking enemy. When this happened during castle warfare, an underground sword battle would ensue, and if the defenders were victorious they would simply collapse the tunnel. If the attackers won the battle, the defenders would then fall back to the inner wall and start the whole thing over again.
Compensating for Weaknesses
While the focus for defenders was to simply survive an onslaught, a crucial part of defense was a good offense. There were four primary types of weapons at the defender’s disposal – longbows, crossbows, trebuchets and heavy objects.
The closest medieval precursor to modern bows, the longbow, shown in Figure 12, stood the full height of a grown man and required a great deal of upper body strength to operate. The advantage of using a longbow was that it was very accurate in the hands of a master and could be reloaded quickly. A crossbow, shown in Figure 13, required a great deal less strength and skill to operate, as the holder could load an arrow using primarily their leg strength by inserting a foot into the stirrup on one end of the weapon and pulling back with their arms. The downside of a crossbow was that it was less accurate and was much slower to reload. On the other hand, just about anyone could use a crossbow with reasonable accuracy. Nobles of the day considered a crossbow to be a crude and uncivilized weapon since little skill was required to operate it, and it was relatively easy for a lowly pheasant to take out a noble knight.
Figure 12: A Longbow
Figure 13: A Crossbow
Taking firepower to the next level, small trebuchets could be mounted on top of walls and fired down into the attacking army. This was the weapon of choice to fight against siege engines such as attacking trebuchets and catapults. Finally, heavy objects could be dropped onto the heads of soldiers from bastions or murder holes. A murder hole was an opening in the ceiling over ground paths through which attacking soldiers would run. Yep, they were really called murder holes, and for a good reason - arrows and stones would be fired or dropped from above with devastating results.
Now, what do those tactics have to do with modern network security? For starters, the structures that defenders built on top of walls were called ‘outer works’, as they were built on the outside of the wall, and extended into the courtyard, or in our modern terminology, into the DMZ. As we mentioned, these were often called bastions, and bastion hosts are the modern-day equivalent in that they are hardened against attacks and placed in the most vulnerable position where they are sure to take direct fire from hackers.
The reason that castle defenders had to resort to using offensive weapons and the bastions from which they were launched is very applicable to our modern challenges. If walls by themselves were truly strong enough to repel any attack, then there would have been no need for soldiers or weapons. But the reality was that while stone walls were the primary defense for a castle, they had some glaring weaknesses, and it was just a matter of time before they fell. Without soldiers and weapons to help repel invaders, the walls would be ‘breachable’ 100% of the time. So, castle defenders implemented compensating measures to offset the weaknesses of walls. A compensating control makes up for a weakness in another security control, and by implementing defense-in-depth, we have a much stronger defense.
As a modern-day example, setting up a DMZ inside of the external firewall to provide a secondary security zone compensates for the fact that firewalls will not stop all malicious traffic. Or, an IDS can be seen as compensating for traffic that gets by the firewall. Just as there never existed an ‘unbreachable’ stone wall, there is no such thing as an ‘unhackable’ network. In both cases – ancient and modern - the best we can hope for is to compensate with additional controls and hope that the attacker concludes it is not worth their time and move on. There were many recorded cases in which an attacking army would simply march right past a castle and attack someone else because the cost of taking over the closest castle would have been too high. Our best defense is to ensure that taking down our system is simply not worth someone’s time.
High Cohesion and Low Coupling
If you have ever constructed anything with walls – a house, a desk, fences - heck, even a dog house -then you probably know how easy it is to build a structure with square corners as opposed to rounding them. While round corners look much nicer, they are not easy to construct. That is why early castles took the easy approach and built everything square. Unfortunately, from a physics perspective square corners are not nearly as strong as rounded corners when catapults start throwing large stone rocks. Castle builders eventually switch to constructing rounded corners instead, and it is not unusual to find castles in Europe that have both older square and newer rounded corners, as they were repaired and enhanced over the centuries.
Now, why are rounded corners stronger, and what does that have to do with modern security issues?
A square corner focuses its entire strength in a single, vulnerable spot where the two walls come toget
her in a 90-degree angle. The stones on the outer edge are incredibly easy to dislodge with a single perpendicular shot, as shown in Figure 14.
Figure 14: Weak Square Corners
Since the majority of the wall’s strength is focused in a single area – the corner - we can say that the wall overall has a low cohesiveness, because one part of the wall is trying to do too much. A round wall, on the other hand, distributes its strength across the entire wall, and every stone is responsible for contributing a small but equal amount to the wall’s overall strength. Each stone in a round wall is said to have a high level of cohesiveness – it is not trying to take on too much responsibility and is instead focused on its own little world instead of trying to be the hero of the wall, much like a corner stone might. As shown in Figure 15, each stone in a round wall is highly cohesive, and an attack against it will result in only a small amount of damage, even if that stone is completely obliterated.
Figure 15: Stronger Rounded Corners
Note also that a single shot against the square wall took out not one, but two stone blocks because they were tightly coupled at sharp angles. Contrast that to the round wall, where the neighboring block barely felt the impact – the stone blocks in this case were connected at a very slight angle, or we can say they were loosely coupled. By using a round structure, walls were better able to withstand catapult fire, and were therefore available for a longer time.
Now, why are we using such strange words such as ‘cohesiveness’, ‘coupling’ and ‘availability’ to describe stone walls? Because those terms are used to describe secure services that must stand up to a hacker’s onslaught just like a stone wall was expected to resist an invading army’s catapult attacks. While I agree they are really bad names to convey the associated meaning, I didn’t invent them. Regardless, let’s apply the concepts to modern infrastructure.
The stone blocks that must survive an attack represent web pages, web services, or any other component-based offering that is Internet-facing. We’re going to assume we are talking about a web service to make it simple. Each catapult-thrown stone represents an attack against a given service, either to take the service down or perhaps to break through any security it tries to put up. Our goal is to reduce the attack surface for each service to the minimum amount, so that it is resistant as possible to any attack. Bottom line – we want to increase the availability of the service as much as possible by maintaining a high cohesion and low coupling. These three concepts are core to any effective security stance.
Any time a service attempts to do too many things, it has a low level of cohesion. The best litmus test for estimating the level of cohesion is to name a service according to everything it does at a high level. If you have to use the word ‘and’, then the service is not cohesive and needs to be broken apart. For example, if a service can be called ‘SignInAndChangePassword’, then it needs to be broken into two services, ‘SignIn’ and ‘ChangePassword’. Why is this important? Because as the complexity of a service increases so does its attack surface. Just as the stone blocks at the corner of a wall attempt to do too much and protect the entire wall, complex services are more susceptible to attacks.
When a service is tightly coupled with another service, our attack surface also increases because an attack on one service will result in multiple services going down. For example, consider a set of sign-in services where we must call ‘HashPassword’ that returns ObjectA, which is then passed into ‘GetCurrentHash’ that returns ObjectB, which is then passed into ‘ComparePasswords’. If ‘HashPassword’ goes down, then the other two services go down as well since there is no way to create ObjectA or ObjectB. This is an example of high coupling, or tight coupling. When a service is self-sufficient and does not explicitly require the output of another service, it is said to have low coupling. Look at Figure 16 and Figure 17 to compare the result of a denial of service attack on a set of services with high coupling, and a set with low coupling. When a service has both high cohesiveness and low coupling, its attack surface is very small indeed.
Figure 16: The Disadvantage of High Coupling
Figure 17: The Advantage of Low Coupling
We can also examine loose coupling by taking a look at how soldiers smoothly operated on top of the wall. Arrow slits, or arrow loops, were holes cut into merlons – remember these were the raised stone structures jutting up from the top of walls that protected archers from incoming fire. By firing from these slits, archers could take their time and aim properly with little fear of an attacking arrow actually making it through the narrow slit. While soldiers worked together and took turns firing through the slit so that a continuous stream of arrows targeted the enemy, each soldier was self-sufficient and if one soldier was taken out or needed a rest, the remaining soldiers simply quickened their rotation and kept going. This is a great example of loosely coupled service – while services play nicely together, a low level of coupling allows them to continue functioning even when a neighboring service is no longer operating correctly. Imagine the chaos if one soldier was responsible for loading the arrow of the next archer. Not only would two archers be taken out if one was no longer able to function, the entire rotation would be thrown into confusion. If a single person was wounded, an entire merlon would be effectively taken out from the battle until the remaining archers could regroup.
Accountability and Non-Repudiation
OK, fair warning: Unlike most of the other analogies between medieval castle warfare and our modern technological world, I will grant this upcoming line of reasoning is stretching the fabric of credibility just a bit. Just put on the same ‘willing suspension of disbelief’ underwear you wore when watching an Avenger’s movie and go with it. This really will help you nail the security concepts later on in the book.
During a battle, soldiers didn’t simply run nilly-willy to a position and start firing. The entire garrison was well-prepared and defensive plans were rehearsed well in advance. Each soldier knew their position and responsibilities and were expected to hold their piece of real estate and ‘grant no purchase’. In essence, if a segment of a wall fell to climbing invaders, everyone knew which soldier failed in their duty. In battle, there was little checking to ensure soldiers were in-place and attentive – they were accountable for their actions, and if they fell short in their duties they could not deny their failure – non-repudiation prevented this since there was ample evidence of the failure and who was at fault. Of course, in medieval times this usually meant the soldier was dead and more than likely would not put up much of an argument any way.
Let’s approach this same concept from a slightly different angle. While logging the various phases and activities of individuals during a battle was probably not the most important thing going on, permanent records of castle battles were often written down after the fact and were used by future castle builders to improve on their predecessor’s successes and failures. These ‘logs’ captured not only large events such as who won and how many lives were lost on both sides, but it often included mundane details such as where various soldiers were placed and how effective they were. Because of the permanent record, soldiers could not later deny, or repudiate, the recorded actions and were therefore held accountable.
In our modern world, enforcing accountability and non-repudiation works in the same manner and is a cornerstone of security. By logging all activities that a user takes, we can hold that user accountable for their actions, and because we have proven the logs are reliable and complete, we have achieved non-repudiation in that a user cannot deny having taken a specific action.
OK, back to a more reasonable discussion.
Single Responsibility
Imagine if an archer was expected to fire arrows and bring water to the trebuchet operators who were thirsty. Or perhaps a soldier in a tower turret watching for enemy advancements was distracted because he was expected to run down and prepare a sandwich for the king whenever the royal tummy growled. If a castle was run in such a manner, it would f
all to an invading army in short order. Instead, in a well-run castle each soldier was assigned a single responsibility and expected to carry it out with the utmost efficiency. In terms of software, a component or service should also do a single thing to prevent complexity and to keep cohesion high. This also has the side-effect of keeping the level of coupling low.
In terms of security though, there is a more dangerous scenario. At the outer gateway, you would usually find a single individual in-charge and was the sole man that could authorize the gates to be opened for a stranger. Imagine if that same person was also responsible for authorizing people to enter the keep. Obviously, there were two sets of rules in-play – just because a person was allowed to enter the courtyard did not mean he or she was allowed to enter the keep itself. If this single individual was distracted because of doing too many things at the same time, he could accidentally authorize a malicious person to enter the keep, when he thought he was only authorizing entry into the courtyard. There are documented cases in which a person was allowed entry to the keep that common sense should have prevented.
To stop such a thing from happening, this responsibility was split between multiple individuals – one at the gate, and a different person authorizing access to the keep. Beyond being a great example of the single responsibility principle, it is also a perfect example of the least common mechanism principle, which states that a single capability should not be used for multiple levels of security control. In terms of software, developers will often write a single function that provides access to publicly-available data such as an office number, as well as to sensitive data such a person’s social security number. Least common mechanism says that we must split this into two functions to ensure we do not accidentally leak sensitive information or make incorrect authorization decisions due to code errors. The two principles of single responsibility and least common mechanism are often closely aligned, and if one is violated more than likely the other has been as well. Look at Figure 18 for an example of the least common mechanism principle.
