Sharks in the Moat

by Phil Martin

  Figure 18: Implementing Least Common Mechanism

  Chapter 3: Defending the Gateways

  Now that we have discussed wall defense in general, let’s focus on a very sensitive area within a wall – the gateway. A wall without a gateway would essentially be useless – while it would certainly be very secure, no one could get in or out. We have already described the basic functions of a gateway and how it aligns with our modern firewall ports, but let’s take a deeper look into the activities around gates and how they map to network security.

  Infiltration

  The primary goal for an army attacking a castle was to take down its walls by either bombarding it with stones or undermining the structure. In some cases, however, taking down a wall would remove the ability for the invaders to march into the protected courtyard. In this case, the defenders would have dug a deep ravine which would be for the most part impossible to climb, and the wall would be built inside of this ravine. While this required a great deal more work and stone, it forced the enemy to preserve the wall and instead focus on gaining entrance through the gateway. Along the same lines a modern hacker would love nothing more than to take down a firewall, but the reality is that it is extremely difficult to do without completely destroying it. If a firewall were to be taken down, it will almost certainly result in the entire internal network becoming instantly unavailable, as a functioning firewall not only blocks traffic but is required for remaining traffic to make it to the other side of the firewall – just like a wall built in a deep ravine. However, a tactic sometimes used by the attacking army was to take down the wall anyway, as the defenders would be unable to leave. The attackers simply had to wait out the

  defenders in a siege, and it became a game of patience. In the same manner, an oft-used hacker tactic is to bombard a firewall with an overwhelming amount of traffic until it becomes unusable, resulting in a denial of service, or DoS, for everyone else. While this does prevent the hacker from stealing data or services, it can cause considerable harm to the company hosting the services.

  A different approach for a hacker would be to leave the firewall intact and attempt to infiltrate into the inner network using subterfuge. In this case, tunneling works not so much as breaking through the firewall itself, but instead seeks to get around the firewall’s rules by encapsulating vicious payloads inside of innocuous-looking packets. You can think of this in medieval times as someone sneaking through a gateway with a crossbow underneath a heavy cloak, or perhaps an enemy soldier disguising their appearance to look like an old woman. In either case, gate soldiers would hopefully detect such deception and bring it to a quick halt. Unfortunately, your run-of the-mill firewall is not nearly as smart as the human brain and is fairly bad at detecting dangerous content. However, firewalls operating at the upper layers of the OSI stack (OSI describes the various levels of network traffic) are able to carry out deep packet inspection, which is equivalent to a castle guard demanding that heavy cloaks be removed to allow soldiers to inspect anything a person is carrying. This would have the negative side effect of slowing down all traffic into a castle so that each person can be inspected. While this would increase security, people would start to complain if the delay became too great. In the same way, deep packet inspection can often slow network performance down so much that users start to complain. This is where psychological acceptance comes into play, as we will soon discuss.

  Identity, Authentication and Authorization

  Obviously, gateway soldiers had to keep a watchful eye on everyone who wanted to enter into the castle. The town around castle walls was usually fairly small – more than a few hundred people was considered to be a fairly large population. Gateway soldiers would therefore usually be able to recognize approaching individuals and verify their identity up-close once they were at the gateway. The soldier could then quickly assess if the person had any legitimate business within the castle walls and deny them access if they did not. A person that was allowed to enter the outer courtyard was not necessarily allowed entrance further into the castle.

  A human brain can easily execute this entire process without delay, but in modern times we have to break it down into three distinct steps before a computer can understand how to carry the various activities out. In terms of castle defense, any unfamiliar visitor would need to claim their identity to the soldier and then provide some type of proof that they were who they claimed to be. This was often achieved by showing a letter from a noble that was stamped with wax seal, thereby authenticating their identity. The soldier would then determine if the person had any need to be in the castle, and what areas inside of the castle they would need access to, thereby carrying out authorization. If the person passed all three tests, he or she was allowed entrance.

  The same process occurs in a typical network. A user claims an identity by entering a user name, and then authenticates that they own the identity by providing a secret password. In some systems, the authentication is even carried out using the same technique that a medieval soldier employed for towns people – facial recognition. Finally, the level of access a user will have is determined by an authorization step that checks their identity against a set of permissions. Figure 19 illustrates the three steps in sequence.

  Figure 19: The Three Steps of Granting Access

  When a castle was expecting an attack and was on high alert, it was not uncommon to deny all entrance unless explicitly allowed by the castellan, or captain of the guard. Instead of the gate soldier making decisions, the castellan would be called up to check the identity of a visitor. Each time this visitor returned, the castellan was still required to come to the front and verify their entrance – just because they had passed all checks once did not mean they could simply walk back in anytime a visitor wished. This approach is called complete mediation where identification, authentication and authorization are carried out for every single transaction and is required if we want to implement a real level of security. In modern infrastructure, this approach requires that every single visit from an outside user is completely authorized – just because they were authorized a few minutes ago is not good enough – we must be able to carry out the full authorization for every round trip. Later when we discuss session management, we will show how this is possible while still maintaining a good user experience. In other words, psychological acceptability must be maintained without weakening security.

  Least Privilege, Deny First, and Separation of Duties

  Another security concept the gateway soldier scenario brings up is that of least privilege. This approach states that any visitor must be allowed only the minimum access required for their visit and no more. For example, just because a noble is visiting a castle does not mean they were given immediate access to the keep – they also had to have a legitimate reason for entering the keep. In terms of computer security, users are given the least amount of access possible while still being allowed to get their job done. A related concept is that of deny first, or denying access to a resource or location unless explicit permission is granted. Within a castle, if a gateway soldier encountered someone they did not recognize then they would refuse to let them in unless someone within the castle with sufficient authority walked over and instructed the soldier to let the visitor pass. In the absence of explicit permission, the soldier was to always deny entrance. We can see that in action when protecting access using a white list instead of a black list. Whereas a black list records everyone who should not be let into the castle, a white list contains the names of only the people who should gain entrance. A white list is what swanky restaurants and Hollywood Emmy parties use – if your name is not on the list, you ain’t getting in, buddy. Properly secured services use a white list to enforce a deny first approach – if a given user is not explicitly allowed to access a service, then he or she is denied the use of that service.

  A third concept often associated with least privilege and deny first is that of separation of duties. If you consider the role of the castellan, his
job was to make decisions, but not necessarily to enforce those decisions. The muscle work was left to the soldiers at the gate. While the soldiers were technically underneath the authority of the castellan, they could act as a check on access decisions and could prevent a rogue commander from letting in members of an attacking force. If the soldier were to act as both decision maker and muscle, he could easily let in the enemy who would then overwhelm the castle soldiers. In the modern world, we mostly use separation of duties to detect and prevent fraud by internal employees, but the concept still holds.

  While we’re on the subject of gate security, let’s take a look at the scenario in which a person would appear at the castle gate and claim they have an important message to deliver. In times of war, unless this person had some pretty strong credentials – such as a letter fastened with an official wax seal – they were not going to get very far. Instead, an important person from within the castle would approach the gate and have the messenger quietly relay the message – perhaps by whispering into his ear - whereupon the insider would deliver the message on behalf of the messenger, acting as the messenger’s proxy. This preserved the castle’s security while still allowing messages to get through. In the modern world, we also sometimes use a proxy server to increase security, as shown in Figure 20. The proxy server will accept a message and turn around and relay it on behalf of the sender, but only if the proxy server understands the message. In other words, proxies add a layer of security by ensuring the message is valid before passing it on, all without letting in dangerous packets.

  Figure 20: How a Proxy Server Works

  Failing Secure

  If you think back, we earlier introduced the idea of using a portcullis to protect a gateway. A portcullis is a heavy wooden gate wrapped in metal to both increase strength and prevent it from catching on fire. The gate usually was made with openings that allowed defenders to see out when it was deployed. While a portcullis was designed to be lowered into place to protect, and raised to provide entrance, castle builders could just as easily have built it into the floor where it needed to be raised to block the passageway. However, in times of emergency it was much faster to let it use gravity to drop down quickly and slam into place, potentially impaling anyone caught beneath such as an attacker. Because of gravity, the portcullis naturally preferred to be lowered, and it took considerable strength to put the gateway in a position of weakness by raising it. Such an approach is called fail secure, and states that when a failure is encountered, a security mechanism must default to a secure state. In this case, if the gears that raised the portcullis broke, the gate would lower automatically and keep the gate secure. Better safe than sorry, right? Now, don’t get the terms fail secure and fail safe confused. Looking at Figure 21, if a portcullis was designed to be fail safe, then it would by default drop underneath the floor where it would not cause harm to anyone. While OSHA might have preferred this as a way to reduce workplace accidents, it would have led to more than one accidental castle breach.

  Figure 21: Fail Secure vs. Fail Safe

  The same principle applies to software security. When a failure such as an unexpected exception is encountered, the software must deny access instead of accidentally opening everything up to a good-for-nothing hacker. The deny first approach to services using a white list is a good example – if we make a mistake and forget to add a service to the white list, then access to that service will be denied as a result. While that might be somewhat annoying to consumers of the service, it is certainly a more secure approach. As another example, let’s suppose we have a function that makes access decisions, returning a ‘yes’ or ‘no’. As shown in Figure 22, if the function is written to return a ‘no’ if we find a reason to deny access, and return ‘yes’ if we make it past all of the ‘no’ decision points, then an exception being thrown right in the middle of the logic will more than likely result in a ‘yes’ being returned, and we have just let a hacker into our ‘keep’.

  Instead, fail secure code as shown in Figure 23 would default to ‘no’ and only return a ‘yes’ if an explicit permission is discovered. An exception in this case would result in a ‘no’ being returned. Instead of having to tell our boss why the database was completely hacked, we only have to deal with a single irritated customer who was denied access.

  private bool HasAccess(User user)

  {

  if (!user.HasPermission(Permissions.Read))

  {

  return false;

  }

  if (!user.HasPermission(Permissions.WriteOrRead))

  {

  return false;

  }

  if (!user.HasPermission(Permissions.IfExisting))

  {

  return false;

  }

  return true;

  }

  Figure 22: Poorly-Written Access Logic

  Economy of Mechanisms

  True to human nature, once the value of a portcullis was recognized, castle builders started going crazy with the idea and over rotated on its use. If one portcullis was good, then why not more? If we’re to be truthful, the use of two portcullis gates in succession was a genius move. By raising the first gate, attackers could rush in, only to run into a second portcullis accompanied by the sound of the first being slammed shut

  private bool HasAccess(User user)

  {

  if (user.HasPermission(Permissions.Read))

  {

  return true;

  }

  if (user.HasPermission(Permissions.WriteOrRead))

  {

  return true;

  }

  if (user.HasPermission(Permissions.IfExisting))

  {

  return true;

  }

  return false;

  }

  Figure 23: Properly-Written Access Logic

  behind them, quite effectively trapping them between the two. This is where murder holes got their name, as defenders would then fire arrows through ceiling holes until the attackers were quite dead.

  Unfortunately, designers added more and more portcullis gates in an elaborate attempt to trap attackers, to the point at which a failure of any one gate would render them all somewhat useless, as they depended on being lowered at exactly the right time and in the correct order. This led to the discovery of the principle of economy of mechanisms, which states that as complexity increases, security decreases. In the case of castle builders, one more portcullis simply increased the chance of a malfunction. In the

  Figure 24: The Relationship Between Code Complexity and Security

  software development world, economy of mechanisms means that we should avoid overly complex designs and code, and instead favor simpler code and fewer features, over scope creep and complex code. As shown in Figure 24, this is closely aligned with the concept of an attack surface, as the security decreases as complexity increases.

  Psychological Acceptability

  We have already mentioned the concept of psychological acceptability several times, so let’s explore that for a second. As we discussed before, there is no doubt that castle defenders could have made their walls even stronger by not putting in any gates at all. Obviously, this would not have been a successful approach since people and supplies needed to pass through the walls. Ignoring the principle of economy of mechanisms for the moment, defenders could also have installed 20 portcullises in each gate, thereby pretty much guaranteeing attackers could not fight their way in before they became exhausted. Unfortunately, it would have taken the common pheasant an hour to navigate the various gates as they were raised and lowered. Therefore, castle designers had to consider psychological acceptability, or the act of striking an acceptable balance between security and ease of use. Modern architects have to deal with the same

  issue, holding back some security measures so that users will be comfortable enough to continue using a system.

  Hidden Messages

  As we mentioned at the beginning of this section, encryption is nothing new
– it has been in-use more than 3,000 years. Only within the last 100 years or so has it taken quantum leaps in complexity due to the introduction of mechanical encryption mechanisms, and later computers. Nevertheless, cryptography was alive and well in the times of castle builders more than 1,000 years ago. Getting cryptic messages into - or in many cases, out of – the castle gateway required messages to be coded in a way that did not arouse the suspicions of soldiers. This is tantamount to modern day TLS traffic passing through a firewall, avoiding detection by an IDS or IPS because those devices cannot peek inside of encrypted packets unless they possess the encryption key. Just as encrypted messages on paper could pass through an attacking army and make it all the way inside of a keep undetected, encrypted packets have the same stealth capability. And just as in castle battles, this capability can be used for either side’s benefit.

  Chapter 4: Other Defenses

  Before we move into a discussion on how the attacking force operated, let’s discuss two more defensive measures that castle builders took advantage of.

  Help from the Outside