Castles, Knights, Satchels and Writs —The Evolution of Security

Todd Simpson
Inovia Conversations
13 min readMar 20, 2020

Digital security gets re-invented continuously; protections evolve as architectures change, as new connected ‘things’ are attached to the Internet, and as attackers find new ways to compromise systems.

Most of the innovations in security are incremental: improvements in behavioral monitoring, identity systems, access control granularity, efficacy of logging and reporting. Recently machine learning has been applied to every layer of security to make that layer faster, better, stronger.

There are also changes in the philosophy of security architectures over time. At a high level this evolution can be seen as the security perimeter shrinking with time, having moved from protecting a corporate network to protecting services to eventually protecting small chunks of data.

When thinking of devices, instead of corporate networks, the same basic progression applies. We used to focus on protecting the entire device, then that advanced to protecting services and apps (solutions like sandboxing), and ultimately will arrive at protecting each important data blob.

Of course, data is often protected today, but not fully in the way it will be in the future, as we theorize here. At some point data will protect itself instead of relying on the security shells that surround it.

This progression is not really a straight line; instead we have periods of “defense in Depth” and then periods of “defense in Breadth” In times of Depth the focus is more on reinforcements than on new architectures; putting more rings of security around the same asset type; this is horizontal movement on our graph below. Defense in Breadth involves more structural change, where the idea of a ‘protected asset’ evolves; these are the vertical movements shown below. Intuitively as the perimeter shrinks you have more ‘things’ to protect; thus the breadth of assets increases.

Note that adding Breadth does not mean you give up on Depth. Security is generally additive over time.

We postulate four main Eras: Castle, Knight, Satchels and Writs. In our analogy Castles and Knights should be well understood. A satchel was used by Knights to carry documents and money — essentially a group of data assets; a Writ was a single proclamation (i.e., a single nugget of data) meant for a specific purpose and for a specific audience. Many writs could be in a satchel, delivered by a Knight to someone in a Castle.

The four Eras are broken into two halves: in the Castle and Knight Eras security was implicit in networks and services; in the Satchel and Writ Eras security becomes the domain of the data itself. This fundamental change between Knights and Satchels occurs when data starts controlling itself. I have marked this with a Δ in the diagram above, as it is a fundamental change in how security is thought about. While the Castle to Knight transition was driven by technology evolution the transition from Knight to Satchel is driven more by societal awareness and demands — partly the tech-lash against existing power structures in Silicon Valley, partly GDPR and CCPA (which are really just kid steps), and partly the socio-political environment where democracies are being challenged by services that don’t have good control of data, are poor stewards of data…or worse yet claim they don’t have responsibility for the data they promote. We are at the start of deep questions around “who owns and controls what data” which gets tied up in who manages free speech, who has the right to publish, access, and control data. And all of this drives a fundamental change in how we will think of security.

Interestingly, this maps out a Strong-Weak-Weak-Strong evolution. This is not to say that Knight + Castle security is weaker than Castle security alone. Obviously not. It is just noting that the addition of Knights is an admission that Castles by themselves are not sufficient. After the Δ we’ll start with the weak version of data centric security before moving to what we know is a better model…but one that we are not yet ready or capable to embrace for a host of reasons. Throughout the entire journey the overall security posture is improving.

Let’s dig in a layer deeper. We can segment our analysis by technology driven changes and societal (people / expectation) driven changes. The two are tightly intertwined, and breaking them apart is not perfect, but can help to give insight into how the next Eras of security may unfold.

Many of the technologies implied here (for Satchels and Writs) already exist. AI, digital ledgers, homomorphic encryption, end-to-end encryption, quantum proof encryption, key management, and a host of others, are all improving. But in many ways they are Satchel-ready today; it is not technology holding us back from the next step in security, it is the will implicit in Δ. This has more to do with people’s motivation, societal demands, and emerging business models than with technology. Like all systems there is status-quo momentum, entrenched interests, and a lack of general knowledge and understanding of alternative solutions.

Castle

Until a decade ago the “Castle and Moat” philosophy for security was the most prevalent. Anything inside the Castle (corporate network) was safe, and since the worst actors never got into the castle, assets inside the castle were largely accessible to everyone allowed over the drawbridge. You built a strong wall and then a moat, called the area in between the two a DMZ, and kept working on building stronger and taller walls as well as wider and deeper moats. For a long time the philosophy of the Castle didn’t change very much, just more layers of “defense in depth” were added. The same idea was used on devices — end-point protection covered the entire device, assuming that if the device was secure, so were all the applications running on that device.

We then realized that no matter how thick the walls or deep the moat, bad actors were going to get in. Trojan horses, willing and dupped accomplices, deep tunnels, tall ladders and every other attack was tried, and many were successful. We also realized that we sometimes hired bad (or negligent) people. We need to start protecting each room in the castle (i.e., the HR room) as well as maintaining the moat and walls. We moved the HR files into the HR room, and started keeping a log of who entered the room, when they entered, and what they touched. We added honeypots and other traps, putting layers of duct tape on the perimeter architecture.

Knight

In the last ten years, spurred by the growth of smartphones, IoT devices and cloud services, the Castle model became inadequate; the endpoints were difficult to control, and corporate assets started to move into third party hosted services. The amount of data companies generated and stored grew exponentially and where that data came from, where it was stored, and who had access to it was not always thought through in advance. The security philosophy changed to acknowledge this: (1) acknowledge that some bad actors would get into the castle, and we should do more to protect against them once they were inside, (2) a lot of corporate assets (including security layers like identity services) were going to exist outside the castle, on BYOD and IoT devices and in cloud services, (3) large cloud providers could actually do a better job of security than any individual company (4) data needed to be encrypted everywhere, and (5) trust relationships became paramount.

The new model was termed “Zero Trust” or Software Defined Perimeter (there is no “inside the castle”; you have to assume everything is out in the open and therefore you need strong identity and verification before allowing anyone onto a service). Google implemented their Beyond Corp approach and a host of fast followers are currently spreading this gospel to the masses. Gartner calls this new approach Secure Access Service Edge (SASE) clearly articulating that you need to protect individual services (who has access to them, what they can do with them, what data they use, who is told about the usage). Since the services can start anywhere (on a tablet, smartphone, IoT device) and end anywhere (cloud service, peer, enterprise) an overlay of identity and access control is used, but each service is responsible for more of its own security.

Using our Castle analogy, the King realized that he needed to secure his full dominion, not just his castle. He trained Knights to defend the security of the realm in a decentralized way; they carried security into the field, defended threats where they were encountered, and reported back on status and issues. Knights implemented services for the king, and the king had to trust his knights. Incentives were put in place and reporting structures were redefined.

We are somewhere in the middle of the transition to Knight centric security models, probably in the realm of the Early Majority on typical technology adoption curves. Vendors have developed alternatives to VPN’s as Knights must provide security for interactions even if they never touch the Castle. Secured peer-to-peer connections, transfer of risk to 3rd parties, and a host of other disruptive changes follow this architectural transition. We will see many more defense in Depth layers built for the new SASE philosophy; swords, armor, shields and lances will evolve.

Satchel

As often happens, as the current iteration of a technology enters the plateau of productivity, a new philosophy is growing with early adopters. Spurred by thinking around digital ledgers (an extreme form of Zero Trust), the ability of AI to address a scale of problems not previously accessible (such as automatically categorizing all data within an enterprise), and the growing focus on appropriate use of data (bias in AI and GDPR / CCPA being two examples), the centrality of data is accelerating. Although Zero Trust started the move towards data being the key element to protect, more so than networks, the segmentation of data for existing Zero Trust implementations revolves around “data required for a service”. If I’m allowed on the service then I’m allowed to use all the data that service accesses. The real transition, which we have termed Satchels in our analogy (but could also be called the Data Defined Perimeter) moves the focus from the service to the data itself. The information the Knight is carrying is fundamental; even if a Knight fails, the satchel should be secure. Only the intended recipient, under the right conditions, should be able to open the satchel, regardless of which Knight delivers it. Data becomes ascendant while services become users of that data.

There are many startups today working to classify, organize, and manage corporate data assets using AI. This is an overlay phase — if they can put similar data into satchels (groups), then they can enforce a better security policy for that satchel. Because companies have their assets spread out all across the enterprise (and now their cloud providers) it wasn’t feasible without AI to actually understand what they have and where it exists. Data segmentation by use case and ACL is accelerating, versus data storage in a single large back end database. Data trails and audits are being generated and sent to advanced logging and analytics services which can highlight inappropriate or unexpected uses.

While the CISO is still involved in Satchel security, the Chief Risk Officer is also now pushing for solutions. The data economy is fully underway and the reputational and business risk for data breaches means that the emphasis on protecting data is now a strategic initiative and involves not only computer technology but also risk transfer schemes and insurance.

The move from Knights to Satchels is an inversion of power structures (consistent with our decentralization theory). It is not about the rights and privileges of services and connections (the Knights), it is about the rights and privileges of data (the documents in the Satchel). Certain data types will allow for certain uses, and all uses will be recorded so that the owner of the data can be assured of its use and the recipient can be confident in its providence. Data becomes the first class citizen, not the services that use it. Improvements in advertising (it is quite possible to have privacy and personalization when serving ads; it just takes a data-centric architecture, not a service-centric one) and bias in AI will be two use cases here, but the philosophy will be widespread.

Writ

This switch to data-centric security models will happen in two stages. The weak stage, being Satchels, will in many cases be “forced” on legacy businesses through regulation, user action, advanced threat vectors, and employee pressure. However, the end game is when the flip to being data-centric really happens, and companies start to differentiate themselves by how they manage and respect data. The “Minimal Data rule” will emerge; the idea that the least possible data is provided to services to do their job (one approach may be homomorphic encryption although less complex strategies will suffice for many use cases) while the maximal auditing of its use is recorded (perhaps with encrypted immutable ledgers). We term this Minimal Data Maximal Audit (MDMA¹). Taking our medieval analogy to its extreme, this is the Writ approach to security. The Satchel may contain lots of different documents meant for multiple audiences. However each writ should be individually capable of enforcing its own security (it is sealed with the King’s seal) so that it is only accessible to the right audience, at the right time, with guarantees on its usage and with strong auditing capabilities. A single Writ is an indivisible unit of data; smaller units don’t make sense.

Of course MDMA also applies to meta-data. As an example of this, consider encrypting an email today. You may succeed in hiding the contents of the message, but the protocol is routed using open text so the sender, recipient, and route are all easy to monitor. A Writ sent by email would not meet the MDMA end goal. Not only the email, but it’s routing, provenance, and usage need to be fully protected.

The Writ approach to security is largely in the research phase today (more from the perspective of how to make it economically feasible and how to upend current power structures than pure cryptology research), and may not see widespread adoption for many years. Stronger identity (with anonymity), scalable digital ledgers (that don’t destroy the planet with their energy requirements), advances in encryption and processing of encrypted data, formal methods for both the data and the meta-data, and business models and regulatory models which encourage MDMA need to be developed. Most important, usable services built using MDMA will have to be compelling enough to get users to move off of existing systems. MDMA gets part of it’s security from privacy-by-design; people will start to recognize that privacy is an essential component of security. Our philosophy towards applications and services will need to change to make this a reality. Despite all that, we see MDMA as the obvious end-game in our “shrinking perimeter” model.

One example of this approach is Tim Berner-Lee’s proposed redesign of the Web itself, an architecture called Solid. While http was designed around connections (services), Solid is designed to separate data from those services and make data pods first class citizens. A Solid pod can be seen as a Satchel, while a piece of data inside a pod can be a Writ (i.e, your social security number). The Solid proposal may or may not gain traction, but the philosophy it embodies is likely to win over time.

The aforementioned Homomorphic Encryption is another early indicator that MDMA is technically feasible. This technology allows a Writ to expose some of its attributes to a service, without giving the service access to the Writ itself. This is a viable approach to MDMA for some types of services and as solutions like homomorphic encryption are developed, the surrounding layers of data management will start to emerge.

As an extension to the digital world, physical assets in the real world will start to be treated like Writ’s — they will get their own digital keys which represent their ownership and provenance, and those keys will require their own security, custody, and insurance. When you buy your electric transportation pod in the future, the keys will be negotiated on the Internet, and you will store your ownership rights in a bank-of-the-future. The security of your pod ownership will not look too different from your ownership of a digital photo. There are a host of startups already offering digital ledger management of physical assets.

Implications for Entrepreneurs and Investors

This framework gives innovators and investors a simple lens to look at opportunities through. It’s not as straightforward as trying to find companies that are “a year ahead” on the curve we have drawn. The curve is not monolithic, although we have represented it that way. Some industries are further ahead (for example, critical infrastructure) because they have higher requirements for advanced security, while some industries are further back as their business goals or user requirements conflict more with existing best practices, let alone future improvements (for example, Castles where the rooms have a high dependence on each other, to it is difficult to segment them fully). It’s important to look at the industry, try to figure out where they are in this evolution, and then invest in opportunities that move them forward from that point.

As hinted at in the table above, business models also evolve with these large structural changes. Selling one-time firewall boxes is now out of vogue, while recurring hosted SaaS services are ascendent. We can expect new business models to evolve as security becomes data-centric. There are hints of these models in the blockchain world, but it is still too early to know exactly how this will emerge.

  1. MDMA is not a bad acronym for Minimal Data Maximal Audit. For many people a full data-centric security model, with the implied privacy, will be a euphoric experience.

2. Thanks to Alex Danco for significant input into this post.

--

--