Security Touches AH Domains

For a moment, ignore the box second from the left titled “Infrastructure Security Component” found in the conceptual diagram (Figure 3.6). For enterprise architects, it’s quite normal to try and treat security as a black box through which communications and data flow. Somehow the data are “magically” made secure. If you work with enough systems, you will see these “security” boxes placed into diagrams over and over again.

Like any practice, the enterprise architect can only understand so many factors and so many technologies. Usually, anyone operating at the enterprise level will be an expert in many domains. The reason they depend upon security architects is because the enterprise architects are typically not security experts. Security is a matrix function across every other domain. Some security controls are reasonably separate and distinct, and thus, can be placed in their own component space, whereas other controls must be embedded within the functionality of each component. It is our task as security architects to help our sister and brother architects understand the nature of security as a matrix domain.* [1] [2]

In Figure 3.7, the security functions have been broken down into four distinct components:

  • 1. Internet facing access controls and validation
  • 2. External to internal access controls and validation
  • 3. Security monitoring
  • 4. A data store of security alerts and events that is tightly coupled to the security monitoring function

This component breakout still hides much technological detail. Still, we can see where entrance and exit points are, where the major trust boundaries exist. Across the obvious trust boundary between exposed networks (at the top of the diagram) and the internal networks, there is some sort of security infrastructure component. This component is still largely undefined. Still, placing “access controls and validation” between the two trust zones allows us to get some feel for where there are security-related components and how these might be separated from the other components represented in Figure 3.7. The security controls that must be integrated into other components would create too much visual noise in an already crowded representation. Another security- specific view might be necessary for this enterprise architecture.

  • [1] * Annoying as the treatment of security as a kind of unitary, magical transformation might be,
  • [2] don’t expect the architects with whom I work to be security experts. hat’s my job.
< Prev   CONTENTS   Source   Next >