Sharks in the Moat

by Phil Martin

  So far, we have approached castle defense as if each castle needed to stand alone. While this was the case in most situations, kings with a little more discretionary spending at their fingertips built and designed multiple castles to work in coordination with each other. The modern equivalent to this approach is called either failover or load balancing.

  A king would sometimes place a strong castle on the front lines of a frontier where an invasion was most likely to happen, and then create one or more castles further away from the likely battle line in case the first castle was overrun. This allowed the occupants to run from the falling castle and escape into the stronghold of the second castle – assuming of course that the attacker had not already blocked the escape route, and the defenders could run really fast. This approach is still a solid design goal with modern technology and is called a failover capability, as shown in Figure 25. When a system fails, or is overwhelmed with too much traffic, the owner can choose to reroute all traffic to a backup system or facility.

  Figure 25: Medieval Version of Failover

  Having to rely on a failover is a worst-case scenario though, and a much better approach would be to prevent the front-line castle from falling at all by leveraging the nearby castles. With this approach, neighboring castles would send reinforcements and supplies such as food and weapons to the castle under attack, as illustrated in Figure 26. Consequently, attacking a castle with a friendly nearby neighbor was always a much riskier outing for the attacking army. We IT people have stolen this idea as well, except that we call it load balancing. This design is achieved when we deploy multiple identical systems that all share in the burden. The end result is that the amount of resources a hacker must throw into a successful attack must be enough to overwhelm all systems taking part in the balancing act. When we discuss this design in deeper detail, you will see we have multiple ways in which to roll out load balancing.

  Figure 26: Medieval Version of Load Balancing

  Leveraging Existing Components

  There is an actual record of a king in northern England that faced a pending threat from the south. His most likely chance for survival was to quickly build a large number of castles in only a few years, and so he set out to not only design a common set of plans that multiple castles could be based on but set up a common source for the needed stone material. Each castle used the same size and shape of stones, so that any leftovers could be used for the next castle to be built. In short, he was the Henry Ford of his day who succeeded by setting up a reproducible assembly line of sorts. Not only did he reach his goal, but he managed to increase the security of his castles by reusing proven designs.

  This has huge implications when designing secure software. By leveraging existing components that have already been proven to be secure, we avoid making mistakes that allow an attacker easier access into our precious internal network. The prime example is to never roll your own encryption algorithm – there are many good

  existing ones to choose from that have been hardened and tested. Additionally, if we can leverage a single component in multiple places, the attack surface is reduced. Of course, this tends to fly in the face of the least common mechanisms principle, so judgement is required.

  Chapter 5: The Attack

  We are finally at the point of describing how the attacking forces viewed the battle for a castle. Whether we are talking medieval armies on foot and horseback, or a hacker hunched over a laptop in a dimly lit apartment, the basic concepts are the same.

  Taking Down the Wall

  There were several ways in which a castle attacker could breach a wall. The quickest way, if successful, was to simply climb over it. In this attack, soldiers would place a ladder against the wall and start climbing up. Unfortunately, this put the climbers in the unenviable position of having to fight off both arrow and sword attacks from above, which was a very difficult stance to succeed from. Defenders would simply push attacker-laden ladders away from the wall, causing them to fall backwards and resulting in some very unfortunate up-close encounters between the ground and the former occupants of the ladder. The attackers then came up with the idea of mounting a ladder inside of a structure on wheels that protected soldiers as they climbed the internal ladder. At the top of this belfry would be a hatch from which soldiers would spring out at the last minute and clamber across the top of the wall. For the belfry to work, it had to be rolled right up against the wall, so defenders started to build curved embankments against the outer walls so belfrys could not be rolled against it.

  Because climbing over a wall ultimately proved to be fruitless, attacking armies mostly gave up on such an approach, but the back-and-forth between increasing attacking and defensive capabilities reflects the same struggle we face in modern times. Each time a new attack vector is discovered, we must respond by plugging a security hole, only to be followed by another newly-discovered exploit. It is a never-ending battle.

  After it became obvious that climbing over walls was not going to be very successful, the attackers turned their attention to brute force attacks with the hope of simply tearing a wall down, or at least opening a hole large enough to crawl through. As we mentioned early on, stone walls would often be 15 to 20 feet thick, so simply using a pickaxe or a battering ram would be useless. Instead, attackers took three approaches as shown in Figure 27 – applying more brute force and going through the wall, bringing down the wall by weakening the ground underneath, or simply trying to go under the wall.

  In the ‘more brute force’ category, a mechanism known as a perrier was invented that could throw a variety of objects into or over a wall. Large stones were thrown repeatedly against the wall in an attempt to chip away until a hole formed, or it collapsed. Unfortunately, the perrier was operated by a large group of men pulling simultaneously on a single rope tied to the short end of the launch beam and was notoriously unreliable in terms of hitting the same spot twice in a row. It was far more effective in throwing objects over the wall such as dead animals or even plague victims. Although we could probably draw up some analogy between virus-laden dead bodies and modern viruses, we’ll resist that particular urge.

  Figure 27: The Three Ways to Get Past a Wall

  Eventually the perrier was updated to use a counterweight and twisted rope to provide launching power, resulting in a far greater accuracy. This machine was called a trebuchet or catapult, and while it was far more effective in bringing walls down it still required days of continuous bombardment to achieve any real results. Gunpowder was eventually imported from Asia, and after a century of further refinement, canons replaced the catapult with deadly results. In fact, the introduction of gunpowder was the prevalent reason for the final demise of castles as a realistic defense.

  There is a great story for us modern cyberwarriors somewhere around gunpowder. I am not 100% confident what it is, but at some point, we are going to discover that a security tool we consider to be crucial to our survival will eventually be tossed due to changing conditions. As an example, in this book we tout the firewall as THE BEST front-line protection against the enemy coming in from the Internet. But there is a growing chorus of people who claim the day of the firewall has already passed due to the nature of changing threats. This argument is beyond the scope of this book, but just Google ‘roger grimes firewall’ to look further into this mindset. Going back in time, I can just imagine the number of holdouts who still believed castles could stand up to a barrage of canon fire, only to be schooled in a very destructive and violent manner as those hallowed walls fell before a gunpowder-induced onslaught. The lesson here is that we must be careful not to hold on to security tactics simply because it worked in the past. We must be forever future-facing. Now, back to the medieval ages.

  In the centuries leading up to the use of gunpowder, brute forcing your way past a wall was only one tool. It was often easier to simply weaken the ground underneath the wall until it collapsed under its own weight, and wall archers were kept busy harassing teams of miners as they
worked. To protect these men, attackers would often construct wooden covers called covered galleries that had the advantage of hiding any progress that was being made. As the tunnel proceeded, wooden beams were used to support the roof of the dirt tunnel. Once sufficient progress had been made the attackers would light a fire with some type of quickly burning accelerant such as pig fat. This would result in a type of explosion that destroyed the wooden beams, collapsing the tunnel, and usually had the satisfying result of collapsing the wall or gateway as well. This would be followed quickly by a rush of the invading army through the breach and into the now-open courtyard.

  This type of attack follows the same pattern we experience from an advanced persistent threat, or APT. An APT is very patient and calculating, willing to quietly dig into our infrastructure and mine it from underneath. APTs will the take one of two actions. They might quietly place backdoors or viruses into our internal infrastructure and continue to exploit it for months or years to come. Or, more like attackers of old, they will set off an explosion that brings everything down around our collective ears. The classic example of an APT with explosive results is the Stuxnet virus, which many attribute to a collaboration between the U.S and Israel. This virus managed to enter an Iranian facility in 2010 and destroyed the bulk of Iran’s ability to generate fissile material needed for their nuclear program. The result set them back many years.

  Not all castle wall mining efforts succeeded in bringing the wall down, however. At times it was necessary to continue the tunnel and attempt to create an opening on the other side of the wall. For this to be successful, the defenders needed to remain unaware of the progress until the attackers burst from the ground on the other side of the wall. As a result, castle defenders were continuously on the lookout for signs of digging such as mounds of fresh earth on the outside or even sounds of tools moving the earth on the inside. At times, the defenders would call for quiet and intently listen to the ground to detect signs of digging. If the castle occupants suspected that a tunnel was being carved out, they would often start digging their own tunnel, with the inevitable result that an underground sword battle took place when the two forces met.

  Of course, castle defenders eventually hit on the perfect defense against attacks design to undermine walls – simply dig a deep ditch against the wall and fill it with water. Called a moat, this countermeasure was quite effective in preventing any serious attacks against a wall other than a direct barrage from catapults or canons. Attackers would have to first drain the moat, if this was even possible, thereby ruining any type of surprise attack through mining. And no, sadly there are no recorded instances of moats being filled with sharks. Only tornadoes have been populated with sharks to my best knowledge.

  While attacks to take down or infiltrate a wall continued, attackers would continue to use hand weapons to great success. As we described earlier, a longbow required a great deal of strength and expertise to operate, but in the hands of a master could be reloaded quickly and used with deadly precision, arrow after arrow. A crossbow, on the other hand, required average strength and no skill whatsoever, such that an average pheasant could fire one with acceptable results. Crossbows suffered from how quickly they could be reloaded and were much less accurate than longbows.

  In modern cyber warfare, these two types of weapons reflect the two general types of attackers – skilled and non-skilled. Longbow hackers have a great deal of expertise, are patient, and generally speaking are very stealthy. As one expert said, ‘The difference between an expert hacker and an amateur is that experts don’t get caught.’ Longbow hackers spend years sharpening their skillset, and usually are in business to make money.

  On the opposite end of the spectrum we find crossbow hackers, who have little to no real skills, make a tremendous amount of noise when attacking, and are usually in it for fun or bragging rights. Unfortunately, just as a pheasant wielding a crossbow can still take down a highly-trained knight, a script kiddie uses weapons created by longbow hackers and can sometimes get lucky. Along this spectrum we find other malicious actors, but we will wait till later for a more in-depth discussion.

  As we described earlier and shown in Figure 28, a common castle design was to have two outer walls, with the strong walls of the keep itself forming the third layer of defense. Some castle designers went even further by dissecting the inner courtyard or keep into two halves such that

  Figure 28: The Three Layers of Defense Common in Castles

  if the wall was breached, the defenders could fall back yet again to the secure half. This promoted a ‘defense in depth’ approach, where wall after wall would have to be defeated before a final victory was declared. Since the keep contained the most precious contents, it was the most well-defended area in a castle and all other defenses were designed to keep the keep out of enemy hands.

  The Attack from Within

  Having an inside force was extremely helpful to the outside attackers. For example, a small group of insiders could quickly defeat gate defenders and open the gates for the attacking force – think of the famous Trojan Horse tale. Although completely fabricated, it illustrates how far a little subterfuge can take you instead of trying a brute force attack. There is a true account of a besieged castle that had previously captured a number of enemy knights and were holding them prisoner within the castle walls. With a little masterful persuasion, the knights convinced their guards to let them loose, whereupon they quickly ran up to one the tallest towers that held a large number of weapons and barricaded the door. From there, they rained down arrows and spears on the defenders from within their own castle, ultimately leading to the defeat of an enemy being attacked on two fronts simultaneously – outside and from within.

  This is particularly relevant to modern networks. If a hacker is able to establish a foothold and plant a virus or backdoor onto an internal computer, then he has effectively taken over a tower and will eventually take you down using your own weapons – namely the computing resources that you used to control.

  The Final Battle for the Keep

  The keep was the ultimate objective in any castle battle. Whomever controlled the keep won the battle. In the event that all outer walls, including the keep’s, were breached castle designers built in a couple of last-ditch security measures in hopes that the final battle could be swayed in the defender’s favor.

  First, secret passages were often a feature designed into a castle, as it allowed the occupants a method for escape if the battle went badly. Unfortunately, if the occupants had not escaped by the time the fight arrived in the keep, it was far too late. Secret passages could also allow soldiers to ambush the enemy by waiting for a group of attacking soldiers to run down a hall, and then suddenly pop out and surprise them from the rear. On the other hand, if the attacker had somehow gained knowledge of these secret passageways due to espionage, they might use them to dive right into the heart of the keep and surprise the defenders. In short, secret passages could be used by either side.

  Today, we face the same struggle with secret passageways in our own software as developers will often build in back doors, or ways to access privileged functionality without going through the normal authentication and authorization mechanisms. Developers will usually implement such a ‘feature’ with nothing but good will, as they wish to be able to diagnose and correct problems in a production environment without having to go through all of the proper channels to get permission. Unfortunately, if a hacker finds out about such a door, he will use it to bypass all security features and either steal your data or cause havoc with the system. Alternatively, a hacker will often breach a system, and instead of carrying out action immediately, he will simply install his own back door using a software program, and leave quietly without detection. This allows him to exploit the secret passageway at a later date when he has time to locate and make off with the crown jewels. As we noted before, secret passages can be used by either side and should seldom be created.

  Besides creating secret passages
, the most minute details were considered when designing the defensive capabilities of a castle. For example, if you ever visit a castle in person you will inevitably find yourself walking up a winding staircase inside of a round tower. If you are lucky enough to be in this position, note that the stairs will ascend in a clock-wise fashion. This means that an attacker – who will already be fighting an uphill battle - will always have his right hand to the wall. As the attacker slashes from left to right, his momentum will be immediately checked by hitting the wall to his right. On the other hand (literally) the defender is free to quickly turn around and slash from the left to the right while in retreat. In addition, you will almost certainly find that you will stumble once or twice as you walk up these stairs unless you carefully watch your feet. Why? Because the builders purposefully made each step different sizes so that it would slow down an attacking force as they ran up the stairs.

  This is a key takeaway that we should remember – if you have a weak spot that cannot be removed, optimize the design such that it trips up an attacker. For example, if we are unable to implement multi-factor authentication by requiring a password AND an RSA token, then ensure the password is really hard to brute force. If we are unable to horizontally scale and are subject to outages due to resource starvation (such as running out of CPU cycles or memory), then be sure to throttle traffic so that users experience long waits instead of the application crashing. Or, if we are unable to properly implement authorization controls into a legacy application, then at least separate database reads and writes into different datareader and datawriter accounts that the application uses to connect to the database. Just like the last-ditch efforts castle designers built into the keep, these security controls can make the difference between annoyance that the battle reached the keep before a defensive victory was achieved, and outright defeat as the enemy walks away with our most precious treasure.