Patterns of Secure Architecture & Security Engineering I

11 min readJul 25, 2019

Fort Bourtange, Groningen, the Netherlands

Defensive and offensive security patterns fascinate me. Deducting logical abstractions of complex security problems has been a money-making venture since the beginning of time.

I would argue that the arms race of the early modern period into the industrial revolution has too many similarities to the current cyber revolution to ignore.

If Mr. Elon Musk started practicing rocket science after reading lots of textbooks, you, too, can own the security architect role on your team by learning from our peers and predecessors.

Today we’ll cover the history of defensive patterns, check out part II for modern-day security patterns.

About the Author

Andrew Douma is a vendor-neutral IT Security Professional. He performs professional audits, penetration tests, and risk assessments. He designs secure networks and engineers high-assurance systems in the Cloud.

You can connect with him on GoodReads, LinkedIn, Medium, and Twitter.

Dutch star forts are cool!

Imagine staring down at aerial images of alien fortifications on a different planet across the Milky Way.

That is what it sometimes feels like when I stare at centuries worth of old Bastion forts while trying to design digital equivalents that adhere to modern security theory.

As you read on, try and predict elements of the next iteration of design — towards you inventing a “theoretically safe” design today.

Above is my birth city of Dokkum, Frisia — Star-shaped fortifications began replacing these Medieval strongholds in the 15th century, whose high curtain walls had become obsolete due to gunpowder fueled cannons.

These new architectural designs from Italy had a relatively flat structure composed of many triangular bastions, specifically designed to cover each other, and the defensive trenches that surrounded them.

17th century plan for a Bastion Fort in Coevorden, the Netherlands

Unique client-tailored architectures were tuned to the natural environment and budget available— some withstood various military blockades entirely, and others gave in after a costly fight.

Over time, forts evolved into complex shapes covering an ever-expansive area, layering in additional defenses the enemy needed to overcome, before compromising their “Crown Jewels.”

Visibility is key

During Medieval times every nearby tree was cut down to not only turn nearby forests into farmland but also enable defenders to spot adversaries “from a mile away.”

“Traditionally” designed round and square turrets left multiple blind spots for defenders, and provided subsequent refuge to attacking adversaries.

To mitigate this vulnerability, the Italian engineers iterated their target state architecture to require diamond-shaped bastion turrets. Applying such security patches after the fact was resource consumptive back then as well.

Fun fact: it is still impossible to fire an unguided high-speed projectile around a curved wall — the principle behind their decision has held up.

Storming the castle

With the defensive 15th-century high curtain walls torn down across the globe — lower but much thicker walls with trenches dug in front of them came into fashion.

Depending on natural and financial resources available, defensive walls would be cut into the natural rock or equipped with a brick facade: brick absorbs shell shock, where stone shatters.

Excavated earth helped create a stable structure by piling it behind, in front, and on top of these defensive walls, dissipating most energy from direct cannon fire and any lucky hits.

Fortifications of this type continued to be useful while adversaries were armed only with cannons, where the majority of the damage inflicted was caused by momentum from the impact of solid shot.

The next iteration included gently sloping mud-ramps stretching as far into the distance as possible, putting even your primary defensive walls out of the direct line of fire. The lower the angle of elevation on these slopes, the better their stopping power.

Perhaps unforeseen by its architects at the time, these convenient mud-ramps made it easier to “storm the castle” and conquer it by throwing bodies at the problem (infantry assault).

In response, trenches became considerably wider, ensuring any storming enemy infantry would still be exposed to gunfire from up high, and heavily guarded defensive cannons had a clear line of fire down the length of each trench. Subsequent tunnel warfare was mitigated by significantly deepening these trenches.

Security is not free

Professionals and nation-states around the world are working on solving the same problem — we may not all speak the same lingo, but many believe security should be free.

Yes, if you have the interest and learn how and whom to learn from, you can teach yourself a lot for free. Many an SMB can accomplish security on a budget. The moment you go Enterprise, all bets are off.

All this Italian security came at a price, Amsterdam’s 20 bastions cost it 11 million florins (about $1.5 Billion of today’s gold!) and Siena bankrupted itself in 1544 to pay for its defenses.

On the flip-side, fortifications were sometimes improvised from earlier defenses, many leaders cutting costs by sticking with flawed architecture and instead opting for the “‘more earth’” and a faith-based approach.

The need for iterative designs resulted in global sales, from Italy to Mexico. For nearly three centuries, Italian security engineers were in high demand throughout the world. Until explosive payloads made their security theory obsolete.

And so, eventually, even the most sophisticated Defense in Depth designs became inadequate with the introduction of payload-carrying Shell projectiles and more accurate gunfire on the battlefields of the 19th century.

Polygonal fortifications

As artillery became increasingly more powerful and shells with explosive payloads came about, security engineers choose a much simpler and more robust design. A Pentagon is one of the possible polygon shapes adhering to this design.

Polygonal style fortifications were laid out in a series of straight lines around a secured area, eliminating flanks. Deep vertical ditches cut into the native rock, covered by defensive blockhouses and firing positions cut into the outer face of the ditch itself.

The majority of any Polygonal fort is underground. The low profile of these forts made them easy to overlook and overshoot.

The development of mortars, high explosives, and the substantial increase in the destructive power of newer explosive shells rendered the intricate geometry of such fortifications irrelevant.

In the 20th century, with the development of maneuverable tanks and aerial warfare during and after the First World War, fixed fortifications became obsolete. Combat was to become more mobile. It took, however, many years to abandon the old fortress thinking.

Modern Security Architecture

The parallels to the ongoing cyber revolution (and covert cyberwar) hopefully jumped out at you — how can you apply lessons learned in our past, today?

Bridge language

Whether it is the Fog of War during an incident or a presentation in front of an unfamiliar audience…

Terms & acronyms which come naturally to you may have an entirely different meaning to your audience.

Confusion or disagreement about what someone intended to convey leads to miscommunication, a common root cause for human indifference and error, resulting in easy exploits against your organization.

So start by establishing a firm foundation — as even your best design will be taken out by a simple miscommunication.

You’ll notice that within each organization, there is a bridge language in use. Concepts within applied information technology pack a different punch to your CxOs, Developers, InfoSec, or Infra teams (DevSecOps.)

Recognizing these common miscommunications and rolling with them is a start. As long as you are aware of this issue, you can succeed. Get creative and publish an internal glossary, and let everyone answer questions individually first, before starting a group conversation.

Security taxonomies exist for both human and machine alike:

Once you’ve established a common language and resources to translate between multiple stakeholders, conflicts may still arise.

Conflict management

Designing any system, let alone a theoretically safe one, is a complex effort that tests the full range of your soft and hard skills.

Consider the unique blend of inherited technical debt, new advances, and corporate culture in general.

People will DISAGREE, and they are either right or under-informed. Or are you biased? Do they have any incentive to care? Apply some logical and critical thinking, be wary of your own bias, and engage these discussions.

When fear/uncertainty/doubt is left unchecked, and employees see a greater reward when avoiding all risk, it often takes a very public embarrassment for your security culture to mature.

What can you influence — and how far are you willing to push it?

What’s a system anyway?

As a first exercise, get your teams on board with speaking the same language, it will be helpful as you engage different groups to determine the scope of what you should secure first.

What “system” are you in charge of securing, and how do you define it anyway? Ross Anderson discusses his definition in greater detail in paragraph 1.7 [PDF, page 9] of his FREE BOOK on Security Engineering.

Ross set an industry standard and is a fundamental InfoSec read — he is working towards a 3rd edition for publishing early 2020.

He contemplates a system to be:

A product or component, such as a cryptographic protocol, a smart card or the hardware of a PC;
A collection of the above + an operating system, communications and other things that go to make up an organization’s infrastructure;
The above + one or more applications (i.e. browser, word processors, accounting app, APIs, and so on);
Any or all the above + IT staff;
Any or all the above + internal users and management;
Any or all the above + external users and customers.

I have stopped differentiating between any type of system, as all are prone to either human or compiler error.

I do weigh the level of security awareness, technical skill, and security maturity in my defensive security designs.

Many systems make the Internet

Nowadays, systems appear to be semi-reliable solutions to their users.

In reality, there are many ever-changing parts, spread across many administrative and technical domains, presented to consumers transparently.

It’s anything electronic on your home and corporate, ISP, cloud, nation-state, and cloud service provider’s network that your employees are engaging with.

One of my absolute favorite reads is Distributed Systems, which defines a distributed system as:

“A distributed system is a collection of autonomous computing elements that appears to its users as a single coherent system.”
— Maarten van Steen / Andrew Tanenbaum

The authors also quote this observation below, dating back to 1987:

“A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.”
— Leslie Lamport

Remember that your loved ones’ financial identities are part of all “Distributed Systems” that collectively make up the Internet. Get your free PDF copy of Distributed Systems.

Architectural pitfalls

Ubiquitous networking enables every electronic device you own to become a force for good and evil — often without your consent.

Despite living at the tail-end of Cloud-powered successes, we have probably all participated in engineering decisions that violated one of the following architectural fallacies:

Systems are similar
Networks are secure
Networks are reliable
Topology rarely changes
Bandwidth is infinite
Traffic latency is near zero
Traffic cost is zero
Legitimate admins are easily identified
Adversaries respect your (future) intent

Enterprises struggle to balance their old, trusted waterfall/agile ways against embracing modern security automation capabilities.

A systemic skill gap and limitations of available products play their role — not every app, persona, or task is DevSecOps compatible.

It is your task to affect positive change!

Traditional Enterprise Architecture

Though I am not convinced Enterprise Architecture (EA) is an effective security strategy, there are several mental models I apply daily.

Recognizing that in a perfect world, a top-down approach based on the following architectural design levels is followed:

Conceptual (security theories and strategies such as #ZeroTrust)
Contextual (determining security principles for your organization)
Logical (draw out high-level functions and processes)
Physical (draw out how you aim to accomplish those)
Component (determine hardware/software choices & maintenance)

Later on in this series, I will cover my take on (Conceptual) security theories such as John Kindervag’s Zero Trust — Ross Anderson does a great job covering more traditional security strategies.

(Contextual) Security Principles are meant to provide overall security guidance that shapes your design decisions, policies, standards, guidelines, and procedures.

Here are two principles I just made up:

Security is too important to be left to only one siloed department or employee — data stewardship, privacy, and incident readiness are everyone’s responsibility — some structure and accountability are required.
Embrace the risk — new technology should neither be feared nor trusted. We should be realistic about each innovation’s potential benefits and dangers. Adopt a business-enabling “yes, and..” communication style.

(Logical) Activity Streams are particular areas of focus to improve and mature the Security Posture of an organization.

There is no limit to the number of logical streams one can identify. Each stream can be a half-pager listing examples of issues observed, and identifying sub-streams (or projects).

If you are interested in diving into the disciplined framework-based approach, traditional EA mandates:

In the real world, many Enterprise Architects specialize in one commercial EA framework and make their career out of promoting that during many Conceptual meetings.

Considering the old “Ain’t Nobody Got Time for That” principle, Network & System Engineers familiar with the lower architectural levels, rarely wander into the upper echelons by their own accord.

Failure to recognize the cross-disciplinary skills and collaboration needed for that “theoretical safe” architecture to translate to a technical design that can be executed on is one root cause why a top-down EA driven approach may fail.

Target State

You are on your way to own the security architect role on your team and contribute towards positive change!

Organizations around the world are openly sharing their responses to the cyber revolution — in the form of Defensive Design Patterns, Technical Implementation Guides, and XML/JSON based Taxonomies.

Continue with part II >

And start exploring the open and iterative approach to a security architecture that is emerging.

Do you have any advice? Corrections or additions?

Do not hesitate to reply. Feel free to share your experiences, advice, and questions in private or through the comments section.