by Phil Martin
Figure 1: Defense-in-Depth
The idea of defense-in-depth was based solidly on the reality that if an attacker breaches one layer of defense, they should immediately be faced with the next layer of defense. The keep itself had very strong walls, so the average castle defense was predicated on three layers of walls that an attacking force had to breach. In modern networks, we also implement walls, called a firewall. Just like castle dwellers, we protect our own keep with an outer firewall, an inner firewall and almost always at least a third firewall built directly around the database. In medieval times, the outer stone wall was the first target of any attack, just as a firewall connected directly to the Internet must bear the brunt of an attack. Outer stone walls were usually the thickest and most protected of any barrier, with the inner wall built of the same material but not expected to endure the same level of vicious onslaught. The area in between the outer and inner wall was called a courtyard, which is a term still commonly used to describe any protected area within an outer wall. When the outer wall was breached, the castle defenders would quickly run inside of the inner wall and close the gate – if you were too slow to make it inside of the inner wall in time, well – it really sucked to be you.
As difficult as walls were to breach, castle builders had to assume they would fall and came up with backup mechanisms in that eventuality. Forming walls into concentric rings was the first attempt to provide redundancy, but other designs were used as well. Some castles used more than one set of walls in the same ‘zone’, such that if the outer wall was breached, the courtyard was divided into two sections with hefty walls dividing each. Called midsecting walls, defenders could quickly fall back into the zone that was still secure, as shown in Figure 2.
Figure 2: Midsecting Walls
The Weakest Link
Before we explore the courtyard further, let’s return to the outer wall and talk about the weakest link for a few minutes. Any wall had to have a way for people to pass through in times of peace, and this was called a gateway. In the early days of castle warfare, an attacker would always attack the gateway first, as it was considered to be the weakest place in any wall, or the weakest link. In response, defenders compensated for this reality by applying additional fortifications around the gateway including one or more portcullises, or gates that were raised to allow entry and lowered into place to protect the gate. A portcullis was made of very heavy wood wrapped in metal and normally took several men to raise and lower. Barbicans were constructed on either side of the gateway, which were heavy, short towers from which defenders could shoot arrows at an attacking army. Additional measures were put into place, some of which we will cover in a little bit. After a couple of centuries of better and better designs, invading armies no longer considered gateways as the weakest link and instead focused their efforts on breaking through anywhere but the gateway. These redirected attacks were undertaken after an assessment of the outer wall was completed and the weakest spots identified. The placement of windows was carefully considered by defenders to ensure attackers could not simply climb a ladder and scramble inside of the castle, and even the size of the window was limited. As a result of this approach, the security concept of the weakest link was founded and still pertains to modern infrastructure today. It doesn’t matter if you have the most secure firewall in the world if it is easy for an attacker to simply plug an Ethernet cable into an office wall and completely bypass your mega-firewall. Your defenses are only as strong as the weakest link.
The Attack Surface
While any castle required a rather large number of people to support it, walls were meant to protect the keep only, not the town that usually resided nearby. While there was certainly sufficient material and manpower to build a wall that encompassed an entire town, such an approach would increase the attack surface to a point at which any invading army would quickly breach the wall. Why? Because most castles normally contained only a small number of soldiers and if the wall was too large it could not be properly defended. Additionally, the more wall there was, the greater the chance that an army could find a weak spot. Modern software deals with the same problem – the larger the code base or the more complex it is, the greater the chance that an attacker will be able to find a weak spot and break through. Calculating an attack surface and how to keep it to a minimum is discussed in detail later, but keep in mind that the simple answer is to keep things uncomplicated and small.
Now, let’s return to the courtyard.
The Courtyard
In a typical castle, there was not much going on in the outer courtyard between the outer and inner walls – at least not in terms of defensive capabilities. This area was sometimes used for grazing pigs and cattle, but when under attack, soldiers seldom were to be found in this area. However, if you were to look upwards at the inner wall, you would find a host of structures that penetrated outwards from the wall and hovered over the ground below. In modern network architecture, this courtyard area is called the demilitarized zone, or DMZ. In military terms, a DMZ is a heavily mined area that is dangerous for either side of a conflict to venture into. In security networking terms, it is a small network, or subnet, that is exposed to the dangerous Internet. Let’s take a look at the various castle wall defenses that protruded into the DMZ and see how they map to modern efforts.
To stay out of arm’s reach of invaders, castle builders built stone wedges at the top of each wall called corbels (Figure 3) that allowed a person to lean out and drop objects, or fire weapons downward, without unduly revealing themselves to enemy fire. Even better, wooden enclosures called hoardings were sometimes built on top of the corbels that allowed defenders to cover dead zones below that would have been otherwise out of reach. A dead zone is an area of the ground that defenders cannot see or reach with arrow fire. Since these wooden hoardings could be set on fire, defenders eventually started building them out of stone, which were called machicolations, as shown in Figure 4. This type of structure, referred to as a bastion, was specifically built to withstand sustained fire from the attackers while protecting their occupants.
Figure 3: Corbels
Figure 4: A Machicolation
Stepping back for a second, the arrangement of concentric walls mirrors the classic DMZ tactic that modern cyberwarfare defenders use. Using defense-in-depth, IT administrators will place a public-facing firewall directly against the Internet, and then raise a second firewall inside of that to protect sensitive infrastructure such as application servers and databases. In between the outer and inner firewalls, you will find hardened components such as web servers and email servers – anything that must be subjected to greater exposure to the enemy. In a clear nod to bastions sitting on top of walls overlooking a courtyard, any hardened server sitting in between the outer and inner walls in the DMZ is called a bastion host. These servers expect to be bombarded with malicious packets and have been built to stand up to attacks while protecting the contents of each host.
The Drawbridge
Castles sometimes employed a long wooden ramp called a drawbridge that could be raised and lowered as needed, or in some cases swung into place from the side. Each concentric wall ring was often connected to its inner companion using a drawbridge, which provided two advantages. First, the gateways could be located well above ground, meaning the attacking force had to climb up the wall to take over the gateway. Secondly, the drawbridge could be withdrawn when needed, denying attackers a key capability to easily move from wall to wall.
In the same manner, we use subnets to create zones such as the DMZ, and ‘bridge’ zones by only allowing traffic coming from a specific IP address and port. For example, the DMZ is allowed to communicate with a protected internal subnet using a single IP address and port range. As a result, just because a hacker has breached the outer firewall and established a foothold in the DMZ, they will still not be allowed to get past the inner firewall except through a single IP address, which is being watched very carefully. Look at Figure 5 for a visual repre
sentation of this security measure.
Figure 5: The DMZ
Figure 6: Segmented Applications
Both concentric and midsecting walls are very applicable to a modern network. If you recall, a midsecting wall bisected a single courtyard into two halves. In the event the outer wall was breached, soldiers could fall back to the half that did not border the breached wall and continue defending the remaining courtyard.
In terms of network layouts, you will often find that a DMZ has been segmented into multiple subnets, with different applications that have no dependence on each other living in separate sibling DMZs. With this approach, if an attacker gains a foothold in one DMZ, it limits the risk to that one application, while the other applications in different DMZs remain secure. This is shown in Figure 6.
Secrets and Distracting the Enemy
Although we will touch on it later, espionage was used quite often prior to an attack to gather intel on the strengths and weaknesses of a castle. When such insider information was not available, an invading force had to resort to observing the outside walls, looking for signs of weaknesses. Defenders sometimes used this to their advantage by making strong portions of the outer wall appear to be weak. If successful, this had the pleasant result of enticing the attacker into expending a good amount of their resources and time breaking through a ‘weak’ area, only to discover that within an even stronger wall was waiting. As an example, some castle builders purposefully made rooms housing latrines to appear to be a weak part of the outer wall, resulting in the attackers wasting time on breaking through, only to discover they had captured something that the castle occupants were trying to get rid of anyway. During this time, the defenders could choose to attempt escape from the other side of the castle, or to simply observe the various techniques an attacker would eventually use when they started to focus on the real defenses. Although castle designers did not use the same term, keeping these design secrets from landing in the enemy’s hands is now called confidentiality, which is simply the act of keeping secrets secret.
Of course, there is a line of thought that says if you have to keep a design secret in order for it to remain useful, it will inevitably be disclosed at some point, rendering the design useless. More specifically, once a castle’s secrets were exposed, they were essentially useless as everyone now knew not to fall victim to that specific trickery. Instead, some castle builders felt it was better to simply create a solid design that still held even if the enemy knew every detail about it. In other words, instead of building fake walls, they favored putting the effort into making existing walls even better. Believe it or not, this conceptual battle still rages today, and it centers on a principle called security through obscurity. Many people, myself among them, believe that any approach that depends on keeping a design a secret is no security at all, since someone will discover it at some point, and the impact will be made much worse than a brute force victory because we will not even know our ‘security’ has been compromised until it is much too late. The term that is the opposite of security through obscurity is called an open design, and it holds that a design should always be open to anyone who wishes to see it. This is why we should always use existing encryption algorithms instead of rolling our own, which is a concept that we will visit more later.
Now, there is a middle ground with the open design argument. While we should not rely on a secret design for strength such as advocated by security through obscurity, neither should we openly boast about our strengths. This behavior in the hacking world is just asking to be punched in the face – hard. Take for example the CEO of LifeLock, Todd Davis, who ran a company protecting people from identity theft. He dared the hacking world to steal his identity, and guess what? You betcha - they did exactly that. Not very bright, if you ask me. Openly bragging about your strength invites abuse upon your head.
Figure 7: Encapsulation
Therefore, while we should not depend on secrets to keep us strong, neither should we advertise our goods for the world to see. This approach is called encapsulation, and in the simplest terms means that we hide complexity behind a single, simple interface that limits the information exposed to the outside world. In the programming world this results in an increasing stability that reduces the attack surface significantly. Shown in Figure 7, we will discuss encapsulation in greater detail later.
Now, all of this discussion does not mean we should dismiss the approach of creating faux castle walls – in fact, quite the opposite is true. The phrase ‘attracting bees to fake honey’ can be used to describe such subterfuge, and this approach has not been lost through the centuries. While they may not have latrines at their disposal, network architects will often deploy a fake server called a honeypot, or even an entire fake network, called a honeynet, to distract attackers and keep them occupied with attacking a seemingly weak spot, when in reality they have been tricked into focusing on a zero-value target. During this time, security personnel can study the techniques the attackers use, and possibly bolster the remainder of the network in the event the attackers discover they have been fooled and move on to the real targets.
New Builds and Maintenance Duties
Most castle walls were built using well-cut stone blocks for the exterior faces, but in between the outer faces a mixture of various stones and lime mortar was poured in all at one time, resulting in a thick liquid ‘mess’ that would cure over time. This meant that walls required decades to reach full strength and were weakest when brand new. Quickly building a castle and hoping for the best was not the safest plan. This is directly applicable to current technology, as newly rolled-out networks, servers and applications follow the same pattern, and are very vulnerable when first introduced before weaknesses are discovered and addressed. When development teams prepare to sit back and relax after the first deployment, they most often find that the real work has just begun as defect after defect starts rolling in, often ruining any chance for a social life for months at-end.
Back at the castle, by properly maintaining walls castle dwellers were assuring integrity, or ensuring that assets remained unchanged, which is a core security concept. It was not uncommon for castles to be updated over the years by strengthening walls, adding towers, or other defensive measures. Even though assets were being changed, integrity was still assured because the changes were authorized by the owners. On the opposite end of the spectrum, if an attacker knocked holes in a wall then the change was certainly NOT authorized by the owner. Therefore, integrity means that changes are not allowed unless authorized.
Castle walls, just like any other physical structure, require maintenance to remain strong, and the castle dwellers had to periodically make repairs. As a result, walls were the weakest right before repairs were carried out since their strength had degraded over time but had yet to be repaired.
Interestingly enough, modern applications exhibit the exact same behavior. Later, we will go into much greater detail as to why this is true, but just
remember that application vulnerabilities tend to spike right before a new version is released.
Chapter 2: Wall Defenses
Now that we have discussed the high-level approaches castle builders leveraged to create a defensible structure, let’s start zeroing in on some specific areas.
Soldiers on Walls
When we start discussing in a bit how an attacking army would try and take down castle defenses, we will focus on the attack against walls, as they were the primary hurdle to overcome. But while there was a good bit of activity focused on the ground close to the walls, an entirely different battle continued to rage at the same time up on top of the wall. Archers would often fire arrows at the soldiers massed hundreds of yards away using both longbows and crossbows, while small versions of catapults were mounted on top of the wall, tossing heavy stones into the army huddled below. To protect soldiers on top of the wall, a variety of defensive structures were built, as shown in Figure 8.
Figure 8: Castle Walls
A parapet was a continuous low wall built along the top of a wall, with merlons rising up every few yards or so to provide protection for soldiers. The gaps in between merlons were called embrasures, and archers would use embrasures to quickly fire an arrow, and then dip back behind a merlon for cover.
Arrow loops, sometimes called arrow slits, were also cut into the merlons so that archers could fire without having to reveal themselves. Vertical slits were used for longbows, and horizontal slits for crossbows. At times the slits would allow both types of weapons to be used, resulting in a cross-shaped slit. Everything was built to allow outgoing arrows while stopping incoming fire.
In modern networks we still use this same basic concept, but we call it ingress and egress routing. Ingress routing allows only friendly incoming IP packets access to the network, while blocking dangerous packets, much as a merlon would do. This is accomplished by examining the source IP address, the targeted port, and in more advanced firewalls, the actual content of the IP packet. Egress routing allows any outgoing IP packet we wish to send. In other words, we can shoot out an IP packet on a specific egress port but deny incoming IP packets to use that same port for ingress. This is illustrated in Figure 9.
Figure 9: Ingress and Egress Rules
Castle gateways did not have the same capability, as once a gate was opened, traffic was allowed in both directions at the same time. Instead, defenders used other measures to bulk up gate security.
