System Architecture Diagrams and Protocol Interchange Flows (Data Flow Diagrams)

Let’s begin by defining what we mean by a representation. In its simplest form, the representation of a system is a graphical representation, a diagram. Unfortunately, there are “logical” diagrams that contain almost no useful information. Or, a diagram can contain so much information that the relevant and important areas are obscured.

A classic example of an overly simplified view would be a diagram containing a laptop, a double-headed arrow from the laptop to the server icon with, perhaps, a brick wall in between representing a firewall (actual, real-world “diagrams”). Figure 3.1 is more less this simple (with the addition of some sort of backend server component). Although it is quite possible that the system architecture is really this simple (there are systems that only contain the user’s browser and the Web server), we still don’t know a key piece of information without asking, namely, which side, laptop or server, opens the connection and begins the interaction. Merely for the sake of understanding authentication, we have to understand that one key piece of the communication flow.^[1] And for most modestly complex systems, it’s quite likely that there are many more components involved than just a laptop and a server (unless the protocol is telnet and the laptop is logging directly into the server).

Figure 3.6 represents a conceptual sample enterprise architecture. Working from the abovementioned definition given by Godinez et al. (20 10)²⁰ of a conceptual architecture, Figure 3.6 then represents the enterprise architect’s view of the business relationships of the architecture. What the conceptual architecture intends to represent are the business functions and their interrelationships; technologies are typically unimportant,

We start with an enterprise view for two reasons:

• 1. Enterprise architecture practice is better described than system architecture.
• 2. Each system under review must fit into its enterprise architecture.

Hence, because the systems you will review have a place within and deliver some part of the intent of the enterprise architecture, we begin at this very gross level. When one possesses some understanding of enterprise architectures, this understanding provides a basis for the practice of architecture and, specifically, security architecture. Enterprise architecture, being a fairly well-described and mature area, may help unlock that which is key to describing and then analyzing all architectures. We, therefore, begin at the enterprise level.

Figure 3.6 Conceptual enterprise architecture.

In a conceptual enterprise architecture, a very gross level of granularity is displayed so that viewers can understand what business functions are at play. For instance, in Figure 3.6, we can understand that there are integrating services that connect functions. These have been collapsed into a single conceptual function: “Integrations.” Anyone who has worked with SOA knows that, at the very least, there will be clients and servers, perhaps SOA managing software, and so on. These are all collapsed, along with an enterprise message bus, into a single block. “Functions get connected through integrations” becomes the architecture message portrayed in Figure 3.6.

Likewise, all data has been collapsed into a single disk. In an enterprise, it is highly unlikely that terrabytes of data could be delivered on a single disk icon. Hence, we know that this representation is conceptual: There is data that must be delivered to applications and presentations. The architecture will make use of “integrations” in order to access the data. Business functions all are integrated with identity, data, and metadata, whereas the presentations of the data for human consumption have been separated out from the business functions for a “Model, View, Controller” or MVC separation. It is highly unlikely that an enterprise would use a single presentation layer for each of the business functions. For one thing, external customers’ presentations probably shouldn’t be allowed to mix with internal business presentations.

In Figure 3.6, we get some sense that there are technological infrastructures that are key to the business flows and processes. For instance, “Integrations” implies some sort of messaging bus technology. Details like a message bus and other infrastructures might be shown in the conceptual architecture only if the technologies were “standards” within the organization. Details like a message bus might also be depicted if these details will in some manner enhance the understanding of what the architecture is trying to accomplish at a business level. Mostly, technologies will be represented at a very gross level; details are unimportant within the conceptual architecture. There are some important details, however, that the security architect can glean from a conceptual architecture.

Why might the security architect want to see the conceptual architecture? As I wrote in Chapter 9 of Core Software Security,²¹ early engagement of security into the Secure Development Lifecycle (SDL) allows for security strategy to become embedded in the architecture. “Strategy” in this context means a consideration of the underlying security back story that has already been outlined, namely, the organization’s risk tolerance and how that will be implemented in the enterprise architecture or any specific portion of that architecture. Security strategy will also consider the evolving threat landscape and its relation to systems of the sort being contemplated. Such early engagement will enhance the conceptual architecture’s ability to account for security. And just as importantly, it will make analysis and inclusion of security components within the logical architecture much easier, as architectures move to greater specificity.

From Figure 3.6 we can surmise that there are “clients,” “line of business systems,” “presentations,” and so on who must connect through some sort of messaging or other exchange semantic [perhaps file transfer protocol (FTP)] with core business services. In this diagram, two end-to-end, matrix domains are conceptualized as unitary:

• • Process Orchestrations
• • Security and privacy services

This is a classic enterprise architect concept of security; security is a box of services rather than some distinct services (the security infrastructure) and some security

Figure 3.7 Component enterprise architecture.

capabilities built within each component. It’s quite convenient for an enterprise architect to imagine security (or orchestrations, for that matter) as unitary. Enterprise architects are generally not domain experts. It’s handy to unify into a “black box,” opaque, singular function that one needn’t understand, so one can focus on the other services. (I won’t argue that some security controls are, indeed, services. But just as many are not.)

Figure 3.6 also tells us something about the integration of the systems: “service- oriented.” This generally means service-oriented architecture (SOA). At an enterprise level, these are typically implemented through the use of Simple Object Access protocol (SOAP) services or Web services. The use of Web services implies loose coupling to any particular technology stack. SOAP implementation libraries are nearly ubiquitous across operating systems. And, the SOAP clients and servers don’t require programming knowledge of each other’s implementation in order to work: loosely coupled. If mature, SOA may contain management components, and even orchestration of services to achieve appropriate process stepping and process control.

You might take a moment at this point to see what questions come up about this diagram (see Figure 3.6). What do you think is missing? What do you want to know more of? Is it clear from the diagram what is external to the organization and what lies within possible network or other trust boundaries?

Figure 3.7 represents the same enterprise architecture that was depicted in Figure 3.6. Figure 3.6 represents a conceptual view, whereas Figure 3.7 represents the component view.

• [1] Given the ubiquity of HTTP interactions, if the protocol is HTTP and the content is someform of browser interaction (HTML+dynamic content), then origination can safely beassumed from the user, from the user’s browser, or from an automated process, for example,a “web service client.”