Unbreakable:

Architecting Highly Secure IT Systems

A White Paper by Roger Sessions

March 2015 Version 1.01

To be notified of new publications by Roger Sessions, subscribe at

rogersessions.com/library/subscribe

Photo by Geoffrey Fairchild made available through Creative Commons and Flickr. Some rights reserved.

2 | P a g e

Table of Contents

Acknowledgements .................................................................................................................................... 3

The Problem of Architectural Security ........................................................................................................ 3

Types of Attacks .......................................................................................................................................... 5

Types of Defenses ....................................................................................................................................... 6

Traditional Architectures ............................................................................................................................ 6

Armored Snowman Architecture ................................................................................................................ 8

Architectures and Security ........................................................................................................................ 11

The Stealth Attack ................................................................................................................................. 12

Defense 1: Resisting a Stealth Attack ................................................................................................ 12

Defense 2: Detecting a Stealth Attack .............................................................................................. 13

Defense 3: Containing a Stealth Attack ............................................................................................. 13

Defense 4: Recovering from a Stealth Attack.................................................................................... 13

Data Breach Attack ............................................................................................................................... 14

Defense 1: Resisting a Data Breach Attack ....................................................................................... 14

Defense 2: Detecting a Data Breach Attack ...................................................................................... 15

Defense 3: Containing a Data Breach Attack .................................................................................... 15

Defense 4: Recovering from a Data Breach Attack ........................................................................... 15

Man in the Middle Attack ..................................................................................................................... 16

Defense 1: Resisting a Man in the Middle Attack ............................................................................. 17

Defense 2: Detecting a Man in the Middle Attack ............................................................................ 17

Defense 3: Containing a Man in the Middle Attack .......................................................................... 17

Defense 4: Recovering from a Man in the Middle Attack ................................................................. 18

Denial of Service Attack ........................................................................................................................ 18

Defense 1: Resisting a Denial of Service Attack ................................................................................ 19

Defense 2: Detecting a Denial of Service Attack ............................................................................... 19

Defense 3: Containing a Denial of Service Attack ............................................................................. 20

Defense 4: Recovering from a Denial of Service Attack .................................................................... 20

Objections to the Armored Snowman Architecture .................................................................................. 20

The Wakeup Call ....................................................................................................................................... 23

Wrap-up .................................................................................................................................................... 24

About the Author ...................................................................................................................................... 26

3 | P a g e

Acknowledgements This paper has been greatly improved by the careful and thoughtful reviews of a number of my

respected peers. I very much appreciate their help. My sincere thanks to the following:

Nigel Bakker, SOA and Integration Architect, Dariel Solutions, South Africa

Jae Charles Call, Principal Software Architect, Vizions Computer Solutions

Indy Dhami, Director, Modulus Management

Rodrigo Estrada, Architecture Services Director, Neoris Mexico

Ron Gates, Senior Developer, Southwest Airlines

Simon Malherbe, Director, CRSMondial

Chris McCauley, Software Architect, EM Solutions, Inc.

Gar Mac Críosta, Chief Adventurer, Business Model Adventures

Mark Reiners

Mario Reyna Salinas, Architecture Manager, Neoris Mexico

A. J. Scotka, Software Quality/Security Engineer, Texas Education Agency

Miles Whitener, President, MultiParadigm Corporation

Scott Widener, Principal, Widener Consulting LLC

Several anonymous reviewers.

The profile picture of Roger Sessions is by Cassie McIntosh of Austin, Texas.

The Problem of Architectural Security We are in a security crisis. This was a major conclusion of the January 2015 Economic Forum, a meeting

of executives from the largest corporations and world leaders. According to a recent New York Times

article1, “Executives were broadly pessimistic on the topic, believing that although a number of

prominent cyberattacks occurred in 2014, this year would only be worse.”

John Chambers, Chief Executive of Cisco, predicted “The number of security incidents this year will be

exponentially greater than last year.” Robert Smith, Chief Executive of the prominent equity firm Vista

Equity Partners, echoed this prediction: “The security breaches that we had in the last 12 months are

going to pale in comparison to these that we’re going to have in the next 12 months.”

“The security breaches that we had in the last 12 months are going to pale in

comparison to these that we’re going to have in the next 12 months.” – Robert

Smith, Chief Executive of Vista Equity Partners

As I write this, we just a few months into 2015 and we have already seen cyber-attacks at Chick-fil-A,

ParkNFly, Book2Park, Starwood, Marriott, and what can only be described as a cyber-catastrophe at

Anthem, the second largest health insurer in the United States. Anthem just suffered a huge data breach

1 http://dealbook.nytimes.com/2015/01/22/in-davos-executives-express-worries-over-more-disruptive-cyberattacks

4 | P a g e

lasting as long as nine months and involving as many as 80 million highly detailed customer records2.

This theft included names, birthdays, social security numbers, street addresses, email addresses,

employment information, and income data. In short, everything one needs to steal 80 million personal

identities.

In a world in which we are seeing major advances in almost every area of IT, why does security stand

alone in getting bleaker and bleaker? I believe there are six reasons for this.

First, the bar of entry into cyber-criminality is becoming very low. Until recent years the development of

malware required advanced programming knowledge. Today sophisticated malware can easily be

purchased over the web or even rented through malware-as-a-service suppliers. As described by Forbes

in February 2015, “[Cyber] Criminal networks have reaped tremendous profits and are investing some of

that into researching and developing more sophisticated methods. As a result, criminals have now

developed expertise that was once the preserve of nation states. More and more, those skills are being

made available for purchase in online forums where anyone can buy them.”3

Second, we are facing the Internet of Things, a world in which security is considered only as an

afterthought if at all. A recent report by IBM4 describes automobile deceleration systems that can be

remotely disabled, building access control systems with unsecured backdoors, and numerous connected

appliances that openly display Wi-Fi passwords. This was the Internet of Things as it existed in 2014 and

it is quickly getting worse. Gartner estimates that the Internet of Things will grow to an installed base of

26 billion units by 2020, far exceeding the installed base of smartphone, tablets, and PCs combined5.

Third, recent high visibility successes will lead to emulation by newly minted cybercriminals. The risks

are decreasing and the notoriety is increasing. Legislation has not kept pace and the international nature

of the offences makes prosecution almost impossible. To date, nobody has been prosecuted for the

lucrative 2014 breaches at P.F. Changs, Michaels, Sony, Target, Home Depot, or any of a dozen other

major incursions.

Fourth, not only are the numbers of breaches increasing, but the categories of breaches are increasing.

In just the last year, memory scraping has been used to breach point of sales machines; ransomware has

emerged as a major threat to data; critical operating system features that have long been trusted have

turned out to be dangerously easy to compromise. These threats were virtually unknown before 2014.

Fifth, cyberterrorism is now a fact of life. Not long ago, cyberterrorism was mostly limited to defacing

web pages. Now, according to McAfee “[cyberterrorists] will attack by launching crippling distributed

denial of service attacks or using malware that wipes the master boot record to destroy their enemies’

networks. These attacks can be very expensive. The recent cyberterrorism attack on Sony is estimated to

have cost $100M6.” A recent survey by Arbor Networks, an expert in denial of service attacks, said “Last

2 http://krebsonsecurity.com/2015/02/anthem-breach-may-have-started-in-april-2014/ 3 http://www.forbes.com/sites/riskmap/2015/02/05/cybersecurity-trends-to-watch-in-2015/ 4 IBM X-Force Threat Intelligence Quarterly, 4Q 2014.

5 http://www.gartner.com/newsroom/id/2636073 6 http://blogs.wsj.com/cio/2014/12/10/the-morning-download-sony-breach-could-cost-100-million/

5 | P a g e

year [2013] just over a quarter of respondents indicated they had seen more than 21 [denial of service]

attacks per month. This year [2014] that number increased dramatically to 38 percent.7” The days of

defaced web pages already seem nostalgic by comparison.

But none of these are the biggest reason we are heading for a security meltdown. The sixth, and biggest,

reason for the downward spiral in security is that we are building large mission critical IT applications

that are inherently insecure. These applications are dangerously easy to compromise regardless of how

much security infrastructure we throw at them. So at the same time that the security threats are

increasing, the critical applications we need to protect are becoming less able to withstand those

threats. This is the perfect storm.

So at the same time that the security threats are increasing faster and faster, the

critical applications we need to protect are becoming less and less able to

withstand those threats. This is the perfect storm.

The reason our applications are so threatened is because their architectures are so weak. Or more

specifically, because the architectural methodologies we are using virtually guarantee insecure

outcomes.

Many security experts describe people as the weak link in the security chain. They claim that if we could

only train people to follow secure protocols, we would have many fewer problems.

I disagree with this assertion. For any large organization it is statistically impossible to ensure everybody

is following proper security protocols all of the time. It only takes a single slip from a single person at a

single weak moment to open Pandora’s Box. We must assume that human frailty is a given and look to

secure architectures to protect us from ourselves.

In the remainder of this paper, I will describe what a secure architecture looks like, why current

methodologies are so flawed, and what we need to change. If we make these changes, we will have a

much more secure IT future. If we couple the tools we have today to build secure infrastructures with a

methodology to architect secure systems, we will have unparalleled security. But we don’t have a lot of

time. The future is already in motion. The bad guys are active and getting smarter.

Types of Attacks While it may seem that there are an overwhelming number of ways the bad guys can penetrate your

system, almost all attacks can be boiled down to some combination of four categories.

Stealth software: This is malware running on a system that is not authorized to do so. Examples

of this include the memory sniffing malware that caused the Target breach8, the ransomware

7 Worldwide Infrastructure Security Report Volume X, available at arbornetworks.com.

8 http://blog.trendmicro.com/trendlabs-security-intelligence/new-blackpos-malware-emerges-in-the-wild-targets-retail-accounts/

6 | P a g e

that encrypts files and demands a ransom before supplying the unencrypt key, the cyber

espionage family of malware that recently crippled Sony, and the zombification attacks that

enlist participation in denial of service attacks.

Data breach: This includes any unauthorized access of the database. This was likely the type of

breach experienced in 2014 by Chase Morgan resulting in the compromise of private data for

more than 80 million customers9.

Man in the middle attack: This describes any breach that involves the interception of messages

between two parties. Examples of this include the October 2014 interception of iCloud login

information in China10, hack attacks on both Google Gmail and Microsoft Outlook11, and an

uncountable number of spoof web sites.

Denial of service attack: This describes an attack that prevents legitimate users from accessing a

web-based service. Examples of this include the Christmas 2014 crash of PlayStation Network

and Xbox Live12 and the December 2014 attacks on the Rackspace domain name system13

These categories are not mutually exclusive, but from a defense perspective it helps to consider them

individually.

Types of Defenses Before discussing methodologies for designing secure architectures, I need to define a secure system. A

secure system is one that mounts an effective four prong defense against attacks:

resists attacks when they are attempted

detects attacks when they have occurred

contains attacks when they have been successful

recovers quickly from the damage that attacks have inflicted

So we have four types of attacks we need to worry about and for each, four defenses we need to

deploy. Now let’s look at our current approaches to application architecture and see why so few of

today’s systems are able to protect themselves from today’s cybercriminals.

Traditional Architectures Traditional architectural methodologies can be categorized as decompositionally-designed, three-tier,

requirements-driven, horizontally-partitioned, iterative methodologies.

9 http://dealbook.nytimes.com/2014/12/22/entry-point-of-jpmorgan-data-breach-is-identified 10 http://www.pcworld.com/article/2835995/apples-icloud-targeted-in-maninthemiddle-attack-in-china.html 11 http://uk.reuters.com/article/2015/01/19/uk-microsoft-china-idUKKBN0KS12720150119 12 http://www.pcworld.com/article/2871692/uk-police-make-arrest-related-to-denial-of-service-attack-on-playstation-and-xbox-networks.html 13 http://www.bizjournals.com/sanantonio/news/2014/12/24/rackspace-recovers-from-denial-of-service-attack.html

7 | P a g e

They are decompositionally-designed because the methodologies start with a high level capability

architecture that is designed by decomposing a large system into smaller and smaller subsets.

They are three-tier because the architectures they produce are divided into a business tier, a services (as

in service-oriented architecture) tier, and a data tier.

They are requirements-driven because the requirements generated at each tier drive the design at the

next lower tier.

They are horizontally-partitioned because the divisions that partition the architecture occur between the

three horizontal tiers (business, services, data.)

And they are iterative because there is a feedback loop that allows requirements to be refined as partial

deliveries are made and deliveries to be modified based on the latest iteration of the requirements.

The traditional IT methodology is shown in Figure 1.

Figure 1. Traditional Architectural Methodologies

The traditional methodologies produce an architecture that is some variant on the architecture shown in

Figure 2. While there are a number of ways this architecture can be implemented, the most common

implementation is as a service-oriented architecture.

8 | P a g e

Figure 2. Traditional IT Architectures

Armored Snowman Architecture The SIP methodology is also a methodology for driving design. For readers who are not familiar with SIP

or the Snowman Architecture, you might want to take a moment to become acquainted with these

ideas14.

SIP stands for Snowman Identification Procedure, for reasons that will soon be obvious. SIP is very

different than the traditional methodologies. SIP can be categorized as an algorithmically-designed, non-

tiered, synergy-driven, vertically-partitioned, parallel methodology.

SIP is algorithmically-designed because instead of the high level architecture being driven through gut-

feel decompositional design decisions; the high level design is driven by precise, reproducible

mathematical algorithms that take as their input well-defined and empirically validated relationships

between business functions. But while the input is well-defined and precise, it is still easily collected

making the data gathering relatively effortless. The SIP algorithms are protected by a U.S. patent15.

SIP is non-tiered because instead of a high level architecture with complex connections between each of

the three tiers, the connections are hidden inside opaque armored structures.

SIP is synergy-driven because instead of using arbitrary, confusing and invariably incomplete

requirements as the linkage between various subsystems, the glue that holds subsystems together is

business synergy relationships.

SIP is vertically-partitioned, because instead of having exactly three horizontal partitions regardless of

system size, we have as many vertical partitions as needed to create a fully optimized system design.

SIP is a parallel methodology because instead of having large independent groups of people that toss

iterations of the product back and forth, we have small teams working closely together in parallel.

14 A good starting place is the three-part blog series that can be found at rogersessions.com/library/blogs#the-snowman-architecture-three-parts 15 U.S. Patent 7,756,735. This patent is for a mathematically-based methodology for minimizing the complexity of large IT systems and enterprise architectures. This patent is the basis for the Snowman Identification Process (SIP).

9 | P a g e

Pictorially, the SIP methodology is shown in Figure 3.

Figure 3. SIP Methodology

The SIP methodology produces an architecture that is some variant on the architecture shown in Figure

4.

Figure 4. Typical SIP Architecture

10 | P a g e

You can see from the above figure why a SIP driven architecture is called a Snowman Architecture16.

Once we have architected and implemented an IT system, the next phase is to lay it onto a machine

architecture. Figure 5 shows both a traditional and a SIP driven architecture side by side.

Figure 5. Traditional Machine Architecture versus SIP Driven Machine Architecture

A Snowman Architecture is characterized by the following:

The clusters of business functions (the head of the snowman) are determined by synergistic

analysis.

The business function clusters (head) determine what services (the torso of the snowman) will

be packaged together. The torso is composed of the services, all of the services, and nothing but

the services that are needed to support the business functions in the head of the snowman.

The service packages (torso) determine how data (the bottom of the snowman) will be

organized. The bottom is composed of the data, all of the data, and nothing but the data that

are needed to support precisely those services in the torso of the snowman.

The only communication to or from a snowman is in the form of messages received or sent by

services in the torso.

Messages between snowmen are always asynchronous and minimized by the algorithms used to

define the head.

Access to the data (bottom of the snowman) is limited to processes in the torso.

16 For a longer introduction to The Snowman Architecture, see The Snowman Architecture, Part I: Overview The Snowman Architecture, Part II: The Economic Benefits The Snowman Architecture Part III: The Technical Benefits These can be found at rogersessions.com/library/blogs#the-snowman-architecture-three-parts

11 | P a g e

When a Snowman Architecture is enhanced to add high security it is called an Armored Snowman

Architecture. In addition to the general characteristics of a Snowman Architecture (above), an Armored

Snowman Architecture also has the following characteristics:

The services package (torso) and the data (bottom) that correspond to a given business function

cluster (head) live on a dedicated physical hardware configuration. In other words, that

hardware configuration will support the torso and bottom of a given snowman and it will

support nothing but the torso and the bottom of that snowman. Where a dedicated physical

hardware configuration is impractical, we will at least have a dedicated virtual configuration.

The dedicated hardware/virtual configuration is enveloped within a highly secure infrastructure.

Examples of components of this infrastructure can include secure communications channels,

firewalls, and packet filters.

The asynchronous messages between snowmen are protected by appropriate levels of

encryption. Examples of these levels include hash digests to check for message tampering,

digital signatures to check for sender authentication, and multi-step authentication to check for

sender impersonation.

The messages going to a snowman are received by specialized services called guards. The guards

manage the incoming message security.

Messages being sent to other snowmen are sent by specialized services called envoys. The

envoys ensure the outgoing message meets the expectations of the guards in the receiving

snowmen.

All messages to or from a snowman are logged. Incoming messages are logged by the guard.

Outgoing messages are logged by the envoy.

There are a number of advantages to the SIP driven architecture when it comes to large IT projects

which I have discussed elsewhere17. In this white paper, I will confine myself to discussing the security

benefits.

Architectures and Security For many readers, Figure 5 is by itself a convincing argument of the security benefits of the Armored

Snowman Architecture. These readers may skip the rest of this section. For the rest, I will go through an

exhaustive analysis. Feel free to skip to the next major section, Objections, when you are exhausted!

The security benefits of the armored snowman approach become apparent when we compare a

traditional architecture to the Armored Snowman Architecture. Keep in mind that we have four

categories of incursions we need to worry about and four categories of defenses we must deploy. Let’s

go through each of these.

17 See, for example, http://simplearchitectures.blogspot.com/2012/12/the-snowman-architecture-part-three.html

12 | P a g e

The Stealth Attack Stealth Software refers to software running on a system that is not authorized to do so. Figure 6

compares a traditional architecture that is uncompromised and compromised by stealth software and

Figure 7 does the same for an Armored Snowman Architecture.

Figure 6. Traditional Architecture Uncompromised versus Compromised by Stealth Software

Figure 7. Armored Snowman Architecture Uncompromised versus Compromised by Stealth Software

Defense 1: Resisting a Stealth Attack

In a traditional architecture, there are no stable rules as to which processes need to run on any given

machine configuration or what their data requirements are going to be. This may change from one

installation to another to accommodate new or repackaged services. It may even change from moment

to moment as processes are reassigned to balance system load. Since previously unknown processes

may need to run on a hardware configuration with little warning, the system can’t be easily locked down

to new processes. This makes authentication and authorization configuration difficult to maintain.

In an Armored Snowman Architecture, it is very clear which processes are and are not allowed to run on

a given hardware configuration. The only processes allowed to run are those containing services that

support the business functions in the head. And the only data allowed on the hardware is data

supporting the services in the torso. This rarely changes. This makes authentication and authorization

configuration easy to understand and easy to administer.

13 | P a g e

Attack resistance for stealth software is therefore much easier to manage on the Armored Snowman

Architecture than it is for a traditional architecture.

Defense 2: Detecting a Stealth Attack

With a traditional architecture, processes are being dynamically allocated to machines on a moment by

moment basis. It is impossible to predict at any given moment what should or should not be running on

a given hardware configuration. This makes it impossible to know whether a given process is a stealth

process or just part of the normal system churn.

With an Armored Snowman Architecture, the process allocation is stable. Once we know which

processes are part of the torso, a stealth process sticks out like a sore thumb. This is easily seen by

comparing Figure 6 to Figure 7.

Attack detection for stealth software is therefore much easier to implement on the Armored Snowman

Architecture than it is for a traditional architecture.

Defense 3: Containing a Stealth Attack

With a traditional architecture, once a stealth process does manage to breach a system, it is like a kid in

a candy shop. Because of all of the demands on the database, the database is minimally protected.

Because of all the processes coming and going, shared memory is ripe for scraping. With synchronous

messages flying back and forth with abandon, reading a message is as easy as reaching up and picking

low hanging fruit. And with the large number of connections between the breached machine and other

machines, the attack can spread throughout the entire data center like wildfire.

With an Armored Snowman Architecture, if a stealth process does manage to breach a system, it is like a

caged tiger. It may look and sound scary, but there is little it can do. The database and shared memory

are accessible only to processes in the torso. The only messages around are protected asynchronous

messages and the patented SIP algorithms guarantee there are a minimum number of those. Finally,

there are few connections to other machines and no connections to other databases, so there are

limited opportunities to spread beyond the initial machine breach.

Attack containment is therefore much easier to implement on the Armored Snowman Architecture than

it is for a traditional architecture.

Defense 4: Recovering from a Stealth Attack

With a traditional architecture, a stealth process can create havoc. Databases can be corrupted. Code

can be destroyed. Machines can be disabled. The breach can quickly spread. Recovery in a traditional

architecture is therefore highly problematic and can take hours, days, or even months (as in the recent

Sony incursion.)

With an Armored Snowman Architecture we have well developed processes for containment, as I have

discussed. Generally the only damage a stealth process can do is to disable the single machine it has

managed to breach. Because a snowman makes such a neat deployment package, it is a simple matter

to redeploy the snowman in toto to another machine (either physical or virtual), data, processes, and all.

14 | P a g e

Attack recovery is therefore much faster and cheaper on the Armored Snowman Architecture than it is

for a traditional architecture.

Data Breach Attack A data breach refers to an unauthorized person reading, writing, or deleting records in a database.

Figure 8 compares a traditional architecture that is uncompromised and compromised by a data breach

and Figure 9 shows the same for an Armored Snowman Architecture.

Figure 8. Traditional Architecture Uncompromised versus Compromised by a Data Breach

Figure 9. Armored Snowman Architecture Uncompromised and Compromised by a Data Breach

Defense 1: Resisting a Data Breach Attack

In a traditional architecture, there are many processes, both on and off this machine, that need access

to the database. Because of the highly dynamic nature of the database access patterns, the demands on

the database are constantly changing. This makes effective database configuration almost impossible.

The more difficult it is to configure the database, the more likely it is that unexpected holes will be left

through which unauthorized people or processes can sneak in.

15 | P a g e

In an Armored Snowman Architecture, the only processes that are allowed to access the database on a

particular machine are the processes in the torso of the snowman running on that machine. These

processes are stable and change infrequently. This makes it easy to configure the database. The torso

processes are given all of the access they need and everybody else is locked out completely. This means

we must make sure bad guys can’t get to the torso processes. This is handled by the guards not the

database. This is an easy and stable database configuration. The easier it is to configure the database,

the more likely it is that there will not be any holes left through which unauthorized people or processes

can sneak in.

Attack resistance for data breaches is therefore much easier to implement on an Armored Snowman

Architecture than it is for a traditional architecture.

Defense 2: Detecting a Data Breach Attack

With a traditional architecture, many processes are accessing the database in highly unpredictable

manners. Therefore when a data breach occurs, it is difficult to recognize unexpected patterns of data

access. Therefore data breach incursions are difficult to detect and often continue for days, weeks, or

months.

With an Armored Snowman Architecture, data access occurs in highly predictable patterns. In the

unlikely event that a data breach occurs, anomalies in data access patterns such as any data access not

initiated by a torso process are obvious and easy to detect.

Attack detection for data breaches is therefore much easier to implement on an Armored Snowman

Architecture than for a traditional architecture.

Defense 3: Containing a Data Breach Attack

With a traditional architecture, there are many processes accessing a highly heterogeneous collection of

data. Who is allowed to access what data under which circumstances is difficult to manage. In addition,

databases are typically linked together so once a data breach does occur, the breach quickly spreads to

a large collection of data.

With an Armored Snowman Architecture, there are very few processes accessing a limited

homogeneous collection of data. Who is allowed to access what data under which circumstances is easy

to manage. In addition, the database on this machine is never connected to any other database on any

other machine. Therefore in the unusual case in which a data breach does occur, the breach is limited to

a small collection of data.

Attack containment for data breaches is therefore much easier to ensure on an Armored Snowman

Architecture than a traditional architecture.

Defense 4: Recovering from a Data Breach Attack

With a traditional architecture, there is little partitioning of institutional data. Data is typically dumped

into the database in a random and haphazard manner. It is almost impossible to tell who owns what

data, who changed what data, and what business processes drove what data decisions. So when a data

breach occurs that results in data corruption, it is difficult to recover the data to a known valid state.

16 | P a g e

With an Armored Snowman Architecture, the institutional data is clearly partitioned. The only data on

this machine is the data used by the processes in the torso. Processes in the torso will update data for

only one of two reasons. Either a business process executed in one of the business functions in the head

of this snowman or a request came in from outside the snowman. These are the only two possible ways

data can get updated. Anything else must by definition be a data breach. Since both business functions

and external requests are logged, it is easy to recover the database to some previous valid state and

then replay the message logs message by message until the database is at a precise, valid state. Any

updates that bypassed the message logs would have done so only because they were from a data

breach, and these will not be duplicated in the recovery process.

Attack recovery is therefore much easier to implement on an Armored Snowman Architecture than it is

on a traditional architecture.

Man in the Middle Attack A man in the middle attack refers to the interception of messages coming into or leaving a system.

Figure 10 compares a traditional architecture that is uncompromised and compromised by a man in the

middle attack. Figure 11 does the same for an Armored Snowman Architecture.

Figure 10. Traditional Architecture Uncompromised versus Compromised by Man in the Middle Attack

Figure 11. Armored Snowman Architecture Uncompromised versus Compromised by Man in the Middle

Attack

17 | P a g e

Defense 1: Resisting a Man in the Middle Attack

In a traditional architecture, once we are behind the firewall there are many messages between

business systems and there are many formats for those messages. Both the messages and the formats

change at a moment’s notice. This gives many opportunities for a man in the middle incursion. Further,

the messages are mostly synchronous. This means that their delivery is time critical. The time critical

nature of the delivery makes it less likely that anybody has taken the trouble and paid the overhead to

protect the messaging channels. And synchronous messaging channels do not have a history of

providing robust incursion resistance.

In an Armored Snowman Architecture, behind the firewall there are few messages between business

systems and these messages have a limited number of formats. Both the number of messages and the

number of formats are highly stable. This means that there are few opportunities for a man in the

middle incursion. Further, in an Armored Snowman Architecture, the messages are mostly

asynchronous. This means that their delivery is much less time critical; delaying delivery by a few tenths

of a second is rarely an issue. Because of the flexibility in time delivery, it is easier to take the trouble

and pay the overhead necessary to protect the messaging channels. In fact, asynchronous delivery

channels have decades of precedent in providing high resistance to attacks.

Attack resistance for man in the middle attacks behind the firewall are therefore much easier to provide

with an Armored Snowman Architecture than for a traditional architecture.

Defense 2: Detecting a Man in the Middle Attack

In a traditional architecture, messages behind the firewall are typically unencrypted synchronous

messages. Further, messages are not logged either on the sending or receiving side. This makes man in

the middle incursion detection virtually impossible.

In an Armored Snowman Architecture, messages behind the firewall are both encrypted and

asynchronous. Further, messages are logged both on the sending and receiving side. This gives us many

ways of detecting a man in the middle attack. If an encrypted message is modified it is obvious because

it is no longer readable. Even if the message is not encrypted, it can be validated with a hash digest to

prove that no changes were made. And we can compare the outgoing and incoming logs. If the logs

match, no incursion has occurred. If they do not match, an incursion has occurred.

Attack detection for man in the middle attacks is therefore much easier to implement on an Armored

Snowman Architecture than it is for a traditional architecture.

Defense 3: Containing a Man in the Middle Attack

As I have mentioned, in a traditional architecture, messages behind the firewall are typically

synchronous. Synchronous messages are typically unencrypted. If messages are not encrypted then

when a man in the middle attack is successful, the man in the middle can easily read, modify, or corrupt

messages in transit. This makes it almost impossible to contain the damage the attack can cause.

18 | P a g e

In an Armored Snowman Architecture, messages behind the firewall are typically asynchronous. It is

standard procedure to encrypt asynchronous messages. When using proper encryption technology,

even in the unlikely event that the man in the middle is able to penetrate the asynchronous

communications channels, there is almost no damage that can result. The man in the middle may be

able to read the message but the message will be crypto-garbled and therefore unintelligible. Any

attempts to change the message will be immediately obvious on the receiving side and the message will

be rejected. This makes it easy to contain the damage that a man in the middle attack can inflict.

Attack containment for man in the middle attacks is therefore much easier to manage on an Armored

Snowman Architecture than it is for a traditional architecture.

Defense 4: Recovering from a Man in the Middle Attack

In a traditional architecture, synchronous messages are flying fast and furious not only to the services on

the machine, but also directly to the database. Once a man in the middle attack has been successful, the

database can easily be compromised. At this point, the man in the middle attack has effectively

escalated itself to a data breach. I have already pointed out the challenge in recovering from a data

breach with a traditional architecture. This also applies to the man in the middle attack.

In an Armored Snowman Architecture, there is only one message destination, regardless of message

type or message origin. This is the guard. The guard logs every message. Even in the unlikely event that

the man in the middle was able to penetrate the asynchronous message channel and in the even more

unlikely event that the man in the middle was able to overcome the encryption of the message,

recovery from the attack is straight forward. All we need to do is remove compromised messages from

the log. A message is compromised when the outgoing log on the sender does not match the incoming

log on the receiver. Once compromised messages are removed from the log, the database is brought up

to a known previously valid state and the uncompromised message log is replayed. The database is now

recovered.

Attack recovery from a man in the middle attack is therefore much easier to manage for an Armored

Snowman Architecture than it is for a traditional architecture.

Denial of Service Attack A denial of service attack occurs when a malicious system overwhelms the victim system with a barrage

of messages so that the victim is using all its available resources to deal with malicious messages and has

no resources left for dealing with valid messages. Figure 12 compares a traditional architecture that is

uncompromised and compromised by a denial of service attack and Figure 13 shows the same for an

Armored Snowman Architecture.

19 | P a g e

Figure 12. Traditional Architecture Uncompromised versus Compromised by a Denial of Service Attack.

Figure 13. Armored Snowman Architecture Uncompromised versus Compromised by a Denial of Service

Attack.

Defense 1: Resisting a Denial of Service Attack

In a traditional architecture, most systems have many incoming message portals. Further, each machine

participates in a web of connections with other machines. Every incoming message portal on every

system is a potential target for a denial of service attack. Protecting this number of targets is difficult.

In an Armored Snowman Architecture, there are few incoming message portals into a system. Further,

each machine has few and limited connections with other machines. Therefore there are only a small

number of potential targets for a denial of service attack. With a small number of targets, it is more

feasible to take the necessary steps to protect each target.

Attack resistance for denial of service attacks is therefore much easier to implement on an Armored

Snowman Architecture than it is for a traditional architecture.

Defense 2: Detecting a Denial of Service Attack

Attack detection for a denial of service attack is easy regardless of the application architecture. After all,

the whole point of a denial of service attack is to bring down the system. Therefore this is one of the few

20 | P a g e

areas where there isn’t a difference between a traditional architecture and an Armored Snowman

Architecture.

Defense 3: Containing a Denial of Service Attack

In a traditional architecture, systems are closely linked together in a tight synchronous web. When one

system in the web is brought down, the many synchronous linkages to other systems make it likely they

will be brought down as well.

In an Armored Snowman Architecture, systems are linked together only as needed. Those linkages are

formed exclusively with asynchronous messages and there are relatively few of these. When one system

in the web is brought down, the asynchronous messaging channels protect the other systems in that

web.

Attack containment for denial of service attacks is therefore much easier to implement with an Armored

Snowman Architecture than it is for a traditional architecture.

Defense 4: Recovering from a Denial of Service Attack

In a traditional architecture, the tight web of systems makes it difficult to separate systems under attack

for the same reasons that it is difficult to contain the attack. And even if the attack point is isolated and

protected, because of the large number of potential attack points it is an easy matter for the attacker to

find another point of vulnerability. Therefore recovery from a denial of service attack can rapidly turn

into a frustrating whack-a-mole game.

In an Armored Snowman Architecture, the closely controlled connection points make it much easier to

separate the systems under attack. Once the attack point is isolated and protected, there are relatively

few other points of vulnerability.

Attack recovery for a denial of service attack means a return to a functioning system. This will be much

easier to achieve with the Armored Snowman Architecture than for a traditional architecture.

Objections to the Armored Snowman Architecture We have shown that the Armored Snowman Architecture is a much more effective approach to IT

security that the traditional approaches. So why doesn’t everybody use it? In this section, I will give the

most common reasons.

Architecture is an art, not a science.

Some argue that architecture is an art, not a science. SIP is based on a highly directed methodology.

That methodology separates critical architectural decisions from non-critical architectural decisions.

Critical decisions are those for which there is little room for error. Even small misjudgments can result in

severe reductions in overall system security. An example of a critical decision is the relationship

between services and data. Non-critical decisions are those that have little impact in overall system

security. An example of a non-critical decision is the name given to those services.

21 | P a g e

When it comes to critical decisions, SIP is unapologetically dogmatic. These decisions will be made

strictly according to the SIP methodology using the patented mathematical algorithms that leave no

room for chance.

If you want artistic freedom we suggest you go into painting.

I’m not a mathematician.

At the core of SIP are the patented mathematical algorithms18. These algorithms are based on set

theory, equivalence relations, and probability analysis. Some architects object to this, saying, “Hey, I’m

not a mathematician.”

You don’t need to be a mathematician to follow a methodology that is based on mathematics. Most

databases today are using relational databases, even though few database administrators understand

the mathematics of relations that underpins these databases.

If you want to help develop the SIP methodology, you need to understand the mathematics beneath the

methodology. If you just want to design secure systems, you just need to understand how to follow that

methodology. Leave the mathematics to the mathematicians.

SIP is Proprietary.

Some think we should not have patented the SIP algorithms. They argue that algorithms this powerful

should have been made open source.

We invested a great deal of time and resources into developing the SIP algorithms. We think it is fair

that we receive a reasonable return on that investment. You will find that the licensing and support we

offer more than pays for itself in reduced complexity and cost savings in dealing with security issues.

The SIP algorithms are new and unique. Nobody else has anything else like them. There is no non-

proprietary solution to the problems SIP solves. In fact, there is no other solution at all. The U.S. Patent

office agrees with this. Receiving a utility patent on algorithms is unusual. Only when the Patent office

agrees that the algorithms are completely new, original, and effective is such a patent granted. The SIP

patent is both broad and deep and will be in force until 2030. It is highly unlikely that any other

organization will be offering a solution that competes with SIP anytime in the near future.

We want proof that SIP works.

Some people want us to prove SIP works. You don’t need us to prove SIP works. You can prove it

yourself. We encourage you to take the SIP directed designs and put them through your most rigorous

architectural reviews. Compare them to designs created with any other architectural methodology. If

you are not convinced that the SIP directed designs are more secure, less complex, and easier to deliver,

18 The mathematics are described in the White Paper, The Mathematics of IT Simplification available at http://rogersessions.com/library/white-papers#the-mathematics-of-it-simplification.

22 | P a g e

don’t use them. You will have invested very little at that point. But if this happens, it will be a first for us.

We have never lost such a competition.

This is just an SOA.

Some people notice the services in the torso of the snowmen and say, hey, this is just an SOA and we

know how to do SOAs. I answer, if you knew how to do them, you wouldn’t be having security breaches.

We like the services technology and use it in our designs. But very few SOAs come even close to the

Armored Snowman Architecture and none use the algorithms that drive the SIP optimizations. This

explains why so many SOAs are such easy prey to cyberattacks. SIP is not just an SOA. SIP is a

methodology for using SOA technologies to build a highly secure architecture.

Most of our systems are legacy.

Some question the need for SIP when so much of their effort is in supporting legacy systems. There is no

doubt that legacy systems are more of a challenge to secure than a system built following the SIP

methodology in the first place. But a careful SIP analysis often shows where vertical partitions can be

added to greatly strengthen the overall security at a relatively low cost. At the very least, a SIP analysis

will point out the greatest security vulnerabilities.

We are going to use the cloud.

Some think they don’t need to worry about security because they are using or going to use The Cloud.

The cloud doesn’t address any of the security issues discussed in this white paper. In fact, most of the

problems are exacerbated on the cloud. The solutions described in this white paper are even more

important for cloud solutions. Anybody who thinks their security problems are going to go away on The

Cloud is in for a rude awakening. For more information on SIP and The Cloud, see the White Paper Cloud

Optimized Architectures for the Public Sector 19.

We aren’t building any large IT systems.

Some think they don’t need SIP because they don’t build large systems. The pay-back size for using SIP

varies by organization. If you are building only standalone systems that are smaller in size than one or

two million dollars, then we agree, there may not be a sufficient return on investment to justify using an

Armored Snowman Architecture and the SIP algorithms. If your systems are around five million dollars in

cost, then you are at the breakeven point. Once your system size exceeds about ten million dollars, the

benefits of this approach become critical. In our experience, building a system in excess of twenty

million dollars without the benefit of the SIP algorithms is dangerous.

We don’t need SIP because we use Agile.

Some think they don’t need SIP because they are already using an Agile approach. We believe in Agile,

however Agile by itself doesn’t scale up beyond about a million dollar project and provides no security

19 Available at rogersessions.com/library/white-papers.

23 | P a g e

protection at all. SIP provides a path for scaling Agile up to the demands of the largest IT projects and

gives it a high degree of protection. Once we have completed the SIP directed vertical partitions

characteristic of the Armored Snowman Architecture, we often recommend Agile for completion of the

parallel projects that will live inside the protection of the snowman armor.

We don’t have time to worry about security.

I’m sorry. I don’t even know how to respond to this.

The Wakeup Call If you have gotten this far, you probably understand the risk your IT systems are facing and the

importance of developing a strong defense. You also understand that this defense must have two

complementary fronts: infrastructure and architecture. The chances are you are already addressing

infrastructure. But if you are like most organizations, you are doing little or nothing to address

architecture. So what should you do?

The first step is lining up executive sponsorship. Adopting the Armored Snowman Approach means

making some important changes in how you design IT systems. Not only will you need to substantially

adapt or even discard some of your current methodologies, you will need to redefine some basic

organizational relationships in your organization. This is going to require visibility and commitment at

the highest executive levels.

Fortunately, this is easier to achieve than ever. As recently as 2014, getting executives to discuss security

was difficult. Today, they are driving the conversations. Executives are acutely aware of the rapidly

escalating cost of security breaches and they are ready to hear about robust solutions. We can help with

executive level presentations that explain the current climate of cyber-hostility and the strength of the

Armored Snowman defense.

The second step is training. Most organizations are not aware of the relationship between architecture

and security. Most architects have little training in designing secure systems and lack even a language to

discuss security. Most business analysts aren’t even aware of their role in designing secure

architectures. We have excellent workshops for training your key players about how to design secure

architectures and the part each role plays in the overall effort.

The third step is evaluating. Most organizations do not introduce the Armored Snowman Architecture

into the entire IT system at once. We recommend evaluating both your current infrastructure and your

current architecture. We will make specific suggestions on strengthening your infrastructure, making

strategic SIP identified modifications to existing systems, and identifying new systems that will most

benefit from adopting the SIP approach.

The fourth step is proving. Actually, this step occurs after every milestone. After the workshops we

prove your staff understands the relationship between architecture and security with certification

exams. After we have developed a proposed Armored Snowman Architecture, we subject the proposed

24 | P a g e

architecture to your most rigorous architectural review. After the architecture has been implemented,

we monitor its success in withstanding the four types of attack.

The fifth step is assimilating. Once your staff understands how to build an Armored Snowman

Architecture and has seen the value in doing so, it is time to incorporate this approach throughout your

organization. We will be there to mentor and support you throughout this transition.

Wrap-up Almost every organization is approaching security from a misguided perspective. They are throwing

security related hardware and software products at poorly designed applications. They are effectively

treating security as an infrastructure problem. One cannot make a bad architecture secure by putting it

in a secure infrastructure any more than one can stop a sieve from leaking by putting it in a safe.

One cannot make a bad architecture secure by putting it in a secure infrastructure

any more than one can stop a sieve from leaking by putting it in a safe.

Of course, infrastructure has an important role to play in securing IT systems. A secure architecture

living in secure infrastructure is going to be highly secure. But a poorly-designed architecture is going to

be insecure regardless of what is done to the infrastructure around it.

The message for organizations is this: security must be approached as a two-pronged problem:

architectural security and infrastructure security. Neither of these can be neglected. This can be seen

from looking at the recent rash of highly destructive security breaches. Almost all of these breaches

occurred at organizations that had put considerable resources into building highly secure infrastructures

and very little resources into designing highly secure architectures.

Infrastructure security is well understood. The tools necessary for building a secure infrastructure are

readily available. Most organizations understand the value of tools such as two-step verification to

protect against impersonation, packet-blocking systems to protect against denial of service attacks,

host-based intrusion detection systems to protect against zero-day attacks, and message encryption to

protect against man-in-the-middle attacks.

However the requirements for building secure architectures are not well understood. Many

organizations have adopted architectural standards that by their very nature compromise security. Thus

we see service orientation leading to cascading system failure, reusability leading to single-points-of-

failure, data sharing leading to information theft, three-tier architectures leading to memory scraping,

synchronous messaging leading to impersonation, and decompositional design leading to general chaos

in both the service and data layers.

One of the most difficult aspects of building a secure architecture is that there is so little room for error.

Any of a thousand bad decisions in the decompositional design can lead to dozens of synchronous

message vulnerabilities. A slight discrepancy between the business and the data architecture can leave

25 | P a g e

the database naked and defenseless. One wrong decision as to what should or shouldn’t be reusable can

result in a system in which denial-of-service attacks spread like wildfire throughout the network.

For small systems, security issues are less of a problem. The opportunities for bad decisions are limited

for systems of less than a million dollars. However the opportunities for bad decisions go up

exponentially as the size of the system increases. Once the system reaches ten million dollars in size, the

opportunities for catastrophic decisions are very high. Most systems of this size have many security

problems even though all or most of them run on very secure infrastructures.

Once the system reaches ten million dollars in size, the possibilities for

catastrophic decisions are very high. Most systems of this size have substantial

security problems.

There are three factors working against us in building large secure systems. First, the margin for error is

so small. Second, the number of critical decisions is so large. And third, the methodologies that drive

these decisions are so non-directed.

A non-directed architectural methodology is one in which architectural decisions are made based on gut

feel, experience, political pull, or any of a number of other useless criteria. All of the common

architectural methodologies today are non-directed methodologies. The larger the system is, the more

likely it is that these non-directed methodologies will lead to failure.

We can’t do anything about the number of decisions that must be made or the seriousness of each of

those decisions. The only thing we can change is the methodology we use for making those decisions.

Specifically, we can go from a non-directed to a directed methodology.

A directed methodology is one that guides each of the critical decisions through some kind of

mathematically based, rational decision making process. The goal is to remove the influence of chance

(or “experience” or “gut-feel”) from the decisions and instead base all critical security related decisions

on well understood, time tested, enforceable, and verifiable algorithms.

Today, the only directed methodology is the one known as Snowman Identification Process (SIP). SIP

uses patented algorithms to drive each level of the architecture, starting with the business architecture,

moving down to the technical architecture, through the data architecture, and finally the machine

architecture. For a given organization solving a given business problem, there is typically one possible

SIP-directed solution20. And that solution can be proven to be the most secure architecture possible.

Once we couple the SIP directed architectural methodology with the secure infrastructures we already

know how to build, we have systems that can stand up to the most rigorous security demands.

For a future characterized by dramatic increases in the number of, types of, and severity of attacks on

our most critical IT systems, we can accept nothing less.

20 For the evidence behind this statement, see The Mathematics of IT Simplification available at http://rogersessions.com/library/white-papers

26 | P a g e

About the Author

Roger Sessions is the CEO of Roger Sessions, Inc. He is

the world’s leading expert in IT Complexity Analytics the

developer of the Armored Snowman Architecture, and

the patent holder on the innovative algorithms that drive

the Snowman Architecture. He has written five books,

dozens of influential articles, and given lectures at

conferences throughout the world.

He has been a guest professor of IT Complexity Analytics

at the University of the Andes and a two time keynote

speaker at the highly prestigious Gartner Research Board

on the topic of IT Complexity Management. His ground

breaking work in Enterprise Architecture and IT has

earned him recognition as a Fellow of the International

Association of Software Architects.

We can help you evaluate the infrastructures and

architectures in your organization from a security

perspective and, where it makes sense, to incorporate

the Armored Snowman Architecture. For more information about the services Roger Sessions Inc.

offers, visit our web site at www.rogersessions.com or write Roger directly at roger@rogersessions.com.