In this series, we’ve discussed what security architecture is conceptually, describing and providing an introduction to some of the standards and frameworks that are involved in effecting it in an organization. The last topic that we will cover before we get into the “meat” of actually performing the work of the architect is that of the roles intersecting the architect’s work as well as an overview of the architecture processes that we will describe in depth and explain how to perform throughout the rest of our book.
First, we’ll walk through adjacent roles that the architect will need to work closely with – and that it’s helpful for them to have an intimate understanding of – in the course of doing their work. These areas, while not exactly a prerequisite to being an effective security architect, can provide quite a bit of value because they intersect so closely with the work that the architect must do. This means that the more understanding of these related disciplines the architect can develop, the more effective they are likely to be and the more productive the conversations they have with the professionals in the roles that they may need to work with directly in the course of realizing their vision will be.
After that, we will walk through the process (at a high level) that we will explain throughout the course of the rest of the book. While there is no “right way” to perform the work of a security architect (the “right way” is the way that works for you), we will describe one approach that has worked successfully for us in doing so. Our intent in providing it is to give those new to the discipline a starting point that they can follow to actually do the work successfully and to share our experiences (and, more importantly, the experiences of others in the profession) with more veteran practitioners who may wish to incorporate new or different techniques into their approach.
Lastly, we’ll walk through (at a high level) the key milestones and tasks involved in the high-level process that we describe. Note that we won’t go into much detail yet – at least in this first introduction – however, it is useful to make sure that those looking to adopt or adapt this approach into their toolbox understand the purpose and relative timing of the stages before they undertake it.
Roles
As mentioned, there are a few related disciplines that, while not architecture exactly, are nevertheless important for the architect to know about as the work that they do is so closely tied to that of the architect. In fact, throughout this book, we will draw heavily upon elements of each of these disciplines, so it is helpful to understand what each is and why it exists in the first place. The three that we will discuss in more detail are the following:
- Security engineering
- Risk management
- Security operations
Without a doubt, there are more roles than this in many organizations that intersect the role of the architect. However, we’ve chosen to cover these three specifically for a few reasons. First, most organizations of mid-market size or larger will have these roles either as a named individual who is assigned to them full-time or as a function that is subsumed into another role. Second, they are synergistic and symbiotic with the security architect. There are numerous other roles that might set requirements (for example, compliance officer, executive management, individual business teams) or that derive benefit from the design put in place by the architect (business teams, technology organizations, and so on), however, the roles we’re drilling into here have a particularly collaborative role to play with the security architect: a “back and forth” and synergy that is different from other roles the organization might have.
Lastly, we’ve picked these roles because, depending on the scope of a particular effort or the organizational makeup, the architect may need to step in to help directly with these other roles.
With that in mind, let’s step through what the first role, Security Engineering is, what it entails, and how the security architect may be called upon to work collaboratively with them.
Security Engineering
Security engineering, strictly speaking, is the discipline of building systems that are resilient to purposeful misuse or sabotage, accident, natural disaster, or other unexpected events. Ross Anderson, in Security Engineering: A Guide to Building Dependable Distributed Systems, Wiley, describes security engineering as “…building systems to remain dependable in the face of malice, error, or mischance. As a discipline, it focuses on the tools, processes, and methods needed to design, implement, and test complete systems, and to adapt existing systems as their environment evolves.” The astute reader will notice that this description and definition is similar to the one that we provided earlier in this chapter in reference to security architecture. In truth, there is a significant overlap in focus, goals, and purview/scope. And, as a consequence, you can probably intuit from the definition alone how closely the two would need to work together in organizations where they both exist (and hence the reason that we’re covering it here).
As a practical matter, there is a difference in the execution of both roles – though, frankly, depending on the organization, there can be wide areas of overlap. Just like a system architect is focused on big-picture design and the vision of the system being developed, the security architect is focused on high-level design and the vision of security within their scope of operation. And just like a systems engineer is focused on the implementation mechanics within that system to make sure all individual components perform appropriately in isolation and together, so too does the system security engineer focus on the components within the system that provide security, their implementation, and their inter-operation.
Given the alignment in interests and goals between the security architect and the security engineer, they will need to work together closely. The security engineer can provide important information to the architect such as the feasibility of implementing a particular type of control in a particular location, strategies and designs to allow security controls to interoperate with each other, implementation guidance, and other important information. Likewise, the architect can provide value to the engineer as well; the architect can help provide input and support to the engineer on control implementation, help champion and whip up support for tools or technologies that the engineer needs, and otherwise work collaboratively with them to the betterment of both.
In situations where there is a defined system security engineering role, security architects should be prepared to work closely with them on a day-to-day basis. Where there is not a defined role – or where the function is spread over multiple other departments – the architect will find that they will need to take on some of this role themselves.
This post is part of a series excerpted from our book: Practical Cybersecurity Architecture: A guide to creating and implementing robust designs for cybersecurity architects, ISBN-13 : 978-1838989927 available at Amazon and published by Packt.