David Rogers continues his blog series — commissioned by on-chip monitoring experts UltraSoC (now part of Siemens) — examining security through the ages and highlighting lessons for emerging and future technologies.
Conwy Castle is an imposing castle. Built towards the end of the 13th of century in North Wales, as part of Edward I’s Iron Ring around the country, its curtain walls are interspersed with eight round towers, complete with arrow slits and ramparts. Its two barbicans guarded entrances to the castle. It still stands today, within the further walls of the town of Conwy itself with a further 21 towers. What is amazing is that it was built within only five years. It was designed by the best castle designer of the day, Master James of St George, and was state-of-the-art when it came to defensive security. It withstood one siege – when the Welsh besieged King Edward in the castle in 1295. It was on Good Friday in 1401 however, that the most interesting events happened at the castle during Owain Glyndwr’s uprising against the English.
Nearly all of the garrison of the castle were at church in the town attending Mass. There were two guards left behind on the gate. A carpenter from the castle approached the guards saying that he needed to perform some work with two of his assistants. They were admitted and then immediately stabbed both guards. They then quickly let in the rest of their men, locking the gates behind them. When the garrison arrived back from church they were unable to gain access to the castle.
Unfortunately, the cleverness of this takeover was undermined by the fact that there were few stores in the castle and the Welsh were not prepared for it. It also upset the King of England, Henry IV, who immediately besieged the castle. Within three months, with no edible stores, the Welsh were starved out.
Why is this story particularly interesting in a technology context? This kind of strategy has many parallels with the way in which hackers often use guile and skill to attack seemingly impenetrable defences. The attack was planned to happen when the castle would be least defended and a way of gaining access via an authorized method had been found. The guards authenticated that the carpenter was real and he was clearly authorized to be there. The defenders were not correctly using their layers of defence within the castle and showed complacency and over-familiarity.
The story also gives a lesson for attackers looking to compromise and remain in a system. When defences have been subverted, one thing that more advanced attackers do in the technology world is what’s called ‘living off the land’. In this case the attackers were not able to sustain their takeover of the castle because they lacked those resources to hold out for a long time. Indeed, they’d misperceived the real situation. In the technology world, it is good practice to minimize in advance the things that an attacker can use once they’re “in the castle” or onto a system, such as software libraries not used for the core operation of a system. In the case of the story above, it was bad luck for the attackers that the garrison had so few usable supplies and food.
We know that Conwy has two barbicans. The purpose of a barbican is to provide additional defence in front of an access point or gate. It functions as a mechanism for control over hostile entrants. Barbicans are typically narrow and often contain traps such as murder holes to throw things down on the enemy, as well as adjacent spaces on the same level and a floor above from which defenders can attack the enemy from the side or from height, whilst safely behind their own defences. The defenders have the advantage because low resources are needed to defend whilst the attacker is narrowly channelled into a place of the defender’s choosing.
In technology terms, we see very little of this kind of defensive mechanism. Where there are inputs to a system, typically via an Application Programming Interface (API), inputs are often blindly accepted, in some cases from anyone who accesses the interface. Good practice dictates that input is validated – ie that a number is indeed a number and within the expected range. However, there is clearly an opportunity to go further than that. Where an interface or system is under attack there is an opportunity to defend against that. Examples of attacks go from fuzzing (throwing structured and unstructured data at an interface in the hope of breaching it in some way), repeated brute-force attempts at getting in, or denial of service (DoS) attacks hoping to overload and consume system resources. Abstractly, a system, once it identifies such kinds of attack, could provide some kind of pre-interface – ie a barbican before the data hits a real interface. This gives the opportunity to do something about an attack as it happens – for example, it could choose to drop the data that is sent during a DoS attack rather than consume system resources responding to it. More sophisticated versions could waste an attacker’s time and resources through other clever means. This is a form of ‘active defence’, without actually ever touching an attacker’s system. It is all performed locally on the system that is under attack.
However, all of this depends on whether the system is always on guard. History shows that in the Conwy castle case, the garrison were complacent – even though the Welsh had started to rebel the year before. The ‘trusted’ carpenter should have been let in on his own without anyone else and there should have been additional guards within the main castle such that the attackers were confined to the barbican itself, to be dealt with.
The castles of yore often included other mechanisms for access control including the use of a portcullis (or sometimes several of them) which could be dropped very quickly if needed to block access or to trap attackers at entry points. Similarly, entrances were often guarded by drawbridges which could be closed, or turning bridges which could easily be destroyed by defenders. Castle buildings often had entrances on the 1st floor and above – well above head-height. This meant that wooden stairs could be destroyed and burnt in a hurry if necessary, causing an attacker further trouble if the castle was under attack. All of these were primarily designed for defending against sieges. As we’ve seen in this blog however, sometimes costly defences can be undermined by guile, intelligence, defender complacency and choosing the right timing.
For more on how historical security measures and failures can help instruct the future of security design for hardware in connected devices, check out the webinar (co-hosted by UltraSoC CSO Aileen Ryan and Copper Horse founder and CEO David Rogers) accompanying this series of blog posts.
Previous blog post in the series << 1/5 Doing nothing in a hostile environment is never going to work out well
Next blog post in the series >> 3/5 Confusing the guards and what it means for future hardware chip design
About the author
David Rogers is Founder and CEO at Copper Horse.