The Medieval castle: the ultimate in defence. A medieval lord, ensconced in his chambers in the keep, could sit by the fire confident that any attackers would need months to penetrate the layers of security that stood between him and the wilds of middle-ages Europe. His protection went beyond a simple reliance on thick stone walls; he was protected by a specific, proven approach to security known as Defence in Depth.
MedStack is also a castle, to apply a metaphor, one that protects patient information. Patient data is highly sensitive, valuable, routinely pulling in more on the black market than any other kind of data including credit cards and bank accounts. Our goal is to allow developers to quickly build software that is HIPAA compliant and that creates and shares patient data so that they can improve care. That means that we must treat patient data as the most important, sacred asset in our system, much as how medieval castles were built with protection of medieval lords and their families as their top priority.
Defence in Depth is the simple principle that while no security is perfect, the presence of many independent layers of defences will geometrically increase the difficulty of an attacker to breach the walls, and slow them down to the point where an attack isn’t worth the expense it would take to initiate it. Each layer multiplies the effects of the previous layer. If the outer wall deters 90% of attacks, and the inner walls deters 90% of attacks, then in combination they deter 99% of attacks. Defence in Depth places the core assets behind layers of varied and individually effective security, each of which has to be circumvented for an attack to be successful.
The Medieval Castle
The medieval castle showed just how well the principle of Defence in Depth can work. Prior to the invention of modern cannons, castles were mostly impregnable, except occasionally when subjected only to long-term sieges. They possessed a level of redundancy in their defences that would seem paranoid by today’s standards. Let’s examine how the feudal lords defended themselves from the outside in.
Defence 1: Contemplating the attack of a castle, the invader was first faced with natural features that worked in favour of the castle. The castle was typically situated at the top of a hill, which made it easy to spot invaders, hence slowing down any attacking army, and made it difficult for attackers to move themselves and any armaments into position.
Defence 2: Next, the attacker had to invade the town attached to the castle, with its own walls, defenders, and barriers. The townspeople not only defended themselves, but also alerted the castle to any incoming attacks.
Defence 3: Having reached the main gate, the invader had to tackle the drawbridge, potentially by building their own bridge across a moat, and then the portcullis, a heavy lattice of wood and iron that dropped down from above. Without access to the winch to raise it back up, the invader had to break through the door, a time-consuming process requiring specialized equipment.
Defence 4: Even if they managed to breach the main gate, at this point they would have only succeeded in breaching the outer wall. A good castle had two walls, with the inner wall overlooking the outer wall. Our invaders troops were now stuck in a confined space between the two walls with arrows and hot tar raining down on them from the top of the inner wall. Penetration of this inner wall required tackling the inner gate, with similar defences to the outer gate.
Defence 5: Assuming that they eventually penetrated the inner gate, their trials were still not over. They had merely reached the inner bailey, the place where most of the business of the castle was conducted. In the bailey were housed the horses, the training grounds, and the vegetable garden. But the lord and lady did not live in the inner bailey, they lived in the keep: a tower attached to it but separated by the final defences.
Defence 6: The keep once again could only be entered by means of a single door, reached from the bailey by a narrow stair. The keep possessed an independent well to protect from poisoning. Breaking through the thick door the attacker would find themself on a narrow spiral staircase. The spirals rose clockwise in order to force the attacker to fight left-handed — a distinct disadvantage for 90% of the population. If they were able to fight their way up several flights of stairs they would at long last find themselves face-to-face with the chests overflowing with gold and jewels, victory at hand.
Needless to say, the instances of successful castle breaches,, penetrating multiple distinct, independent and unavoidable lines of defence, were infrequent compared to the number of attacks.
There’s a lot that we can learn from those military designers who refined their castles over the centuries through the dark ages. They lived in an environment much like the internet of today — chaotic, with their constructions under constant attack. Today’s attackers are crackers operating with digital swords, but the principle and effectiveness of a Defence in Depth approach is much the same.
Defence in Depth in the Cloud
Medieval castle builders knew that defending the crown jewels with a single wall, no matter how massive and fortified that wall might be, was a mistake. Defence in Depth for a cloud server starts with the same principle.
Cyber defence 1: For example, most operating systems have an single root administrative account that can perform any function, and by default, most of them have a single doorway that allows access to this root account from the internet. Arguably the SSH system that protects the root account is extremely strong. On the other hand, an attacker with access to a single stolen password or a single flaw in the SSH protocol — unlikely though that may be — could gain total control of a system in one step. Our goal is to put in place many steps and many barriers. So, the first thing that we do on every system is to disable remote SSH access to root.
Cyber defence 2: Next we set up a firewall, with a default “deny” stance. This is like putting up an outer bailey wall on our castle. Any incoming access is turned down, unless it comes in a few specific channels that were are ready to talk to. Usually, those are only SSH (our secure method to administer the system) and HTTP/S for the web server.
We often also have a “town wall” as well which is operated by an infrastructure provider such as Amazon Web Services or IBM SoftLayer. They each operate their own firewalls and network protection services surrounding our servers, which gives us extra protection and early warning.
Cyber defence 3: The “gates” are each heavily protected themselves. SSH can be protected by two-factor authentication, which takes advantage of a simple principle of identification: When someone approaches the gate, we want to know if they are who they claim to be — if they are, then we let them through; otherwise, we don’t.
A passphrase is a single factor — something that you know — that the system can use to identify you. If you know your password, you are who you say you are. Attackers can exploit the very simplicity of passwords to gain access. First, passwords can be very easy to guess. If you’re reading this, you’re probably not one of the 4% who use “123456”. By some estimates, 10% of users use just 20 unique passwords. Second, passwords can be stolen by malware, sniffed from emails, and snarfed with social engineering.
Checking two or even three factors is far more secure. Gmail can text a special code to your mobile phone when you log in. In addition to your passphrase, you need the code, which proves you have your phone — something an attacker who guessed your password would not have.
Cyber defence 4: Once you’re logged in, you’ve only gained access to the “outer walls” without access to the heart of the system. User access limitations to system controls is the next layer of defence. One example is a user who updates the source code of an application. Even with the ability to alter the source code, this user cannot perform key functions. For example, they can’t destroy any data, they can’t access backups and they can’t alter the log files.
Cyber defence 5: Logging and auditing provide deep security. There’s a famous account of an early computer attack called The Cuckoo’s Egg by Clifford Stoll. By meticulously logging and auditing the use of the system, the author was able to detect the damage being done, and better yet, track down the attacker through a web of intrigue, tracing them back eventually to Germany.
Audit logs track key activity on the system, enabling us to reconstruct activity long after it occurs. This can be useful in the simple case of a server error, but it can also be extraordinarily helpful in preventing and mitigating attacks. We log activity at the operating system level, the database level, the application level, and the HTTP level. All of the logs get rotated, encrypted and stored in a vault where they can be accessed but not modified.
The truism of internet security is that there’s no such thing as perfect security. All internet systems are attacked and many are penetrated each year. The ones that stand the test of time are not necessarily the ones that deploy a single clever form of encryption or a specially designed firewall. The ones that stand up to the chaos of the internet are the ones with many layers of defenses, each carefully maintained and monitored. They are designed like a medieval castle, to provide an oasis of security in an uncertain world.
We have taken this multi-step approach to heart at MedStack. Security and the protection of patient privacy are built into everything we do, along with the risk assessment compliant with HIPAA and, of course, in the tools and recommendations we make to our developer partners. Collectively, we are proud to consider ourselves among the castle-builders of today’s digital health revolution. We encourage everyone in this space to take a similar good hard look at security. If you believe, as we do, that only this high standard will suffice in achieving protection for the citizens of our ecosystem, we’d be happy to discuss — please reach out.
