What is cybersecurity architecture?
The easiest way to understand cybersecurity architecture is through a comparison with the role of an architect in the physical world, such as one who is working on a large structure such as a bridge, tunnel, skyscraper, museum, or a new house.
In the physical world, it's easy to understand what an architect does. We all know that you can't just forego planning and "wing it" when it comes to building a safe, durable, and functional structure. Would you, for example, feel comfortable riding the elevator to the fiftieth floor of a building where they decided to forego planning and "just build it and see if it works"? I wouldn't.
But there's more to it than just safety. There's also ensuring fitness of purpose. Meaning, ensuring that the structure meets the various requirements that drive the reason why the structure is being built in the first place. This can include the following:
- Financial and budget requirements
- Aesthetic requirements
- Functional requirements (that is, that the occupants of a skyscraper can get where they need to go with minimal hassle)
- Timing requirements
Again, this comes down to planning. In the preceding skyscraper example, can you imagine if someone built it but didn't include elevators? An oversight like that would outrage occupants: no residential tenant would want to walk 50 flights of stairs and no business would hold on to customers who were required to do so. In fact, such a structure would be illegal in many parts of the world for exactly this reason. In this case, the "fitness of purpose" for the building isn't realized – and to remediate it after the fact would lead to tremendous expense, wasted time, and needless impact on the building's occupants.
No, in the physical world, the value the architect brings to the table is obvious: they're the keeper of the vision for the structure being built. It is their job to come up with a design based on the requirements of what the structure will do and what it's for, to ensure the fitness of that design for the intended purpose, to make sure the result is realistic in light of the resources available, to work with the many specialists required to implement the vision (for example, to ensure the design is feasible and practical), to ultimately shepherd the project through execution as the final result is brought to life, and to do all the previous things safely.
This, as you might imagine, is easier said than done. It's not a job that exists in isolation. Depending on the type of project, there can be numerous people – or even teams of people – involved: from specialized professionals such as geologists or hydrologists to tradespeople such as electricians and plumbers, to waste engineers and soil specialists, and it even requires in-depth discussions and input with those for whom the structure is being developed (the ultimate users or inhabitants of the structure).
In the enterprise computing world, the role of the architect is directly analogous to the one we discussed. The parallel is so apt in fact that there are often multiple different kinds of architects that can play a role in any technology system. There are system architects, network architects, software architects, cloud architects, data architects, and numerous others. What they all have in common is that, just like in the physical world, they are all the keepers of the vision for their particular area of specialization.
Just like the physical architect ensuring that their structure fits the purpose for which it is being built, the technology architect ensures the fitness for purpose for the technological systems in their area. They construct a design based on the needs of the organization and the goals that organization is trying to achieve, they work with others to vet it and ensure it is feasible, and they craft a plan (in conjunction with other stakeholders and technical specialists) to make the vision a reality.
The cybersecurity architect then is the specific type of technology architect responsible for cybersecurity within an organization. Just like a network or software architect, the cybersecurity architect does the following:
- Identifies the goals and requirements for security
- Develops a vision for how to achieve those goals
- Works with other technical specialists to make sure that their vision is practical and feasible
- Works with those specialists to put a roadmap together
- Works in lockstep with other technologists to make the vision a reality
Network versus application security architecture
Actually, just like there are different sub-types of technology architects generally (for example, data architect versus software architect versus network architect), there can also be different types of cybersecurity architect. This can be confusing, because sometimes it is not clear from a person's title what a practitioner's scope, focus, and purview is.
A cybersecurity architect within one company might be focused almost entirely on network infrastructure, while another with the same title and similar job description at another firm might focus almost exclusively on application design. Different types of cybersecurity architects have different scopes and different tools/methods that they use to help them achieve their goals.
In this book, we've chosen to focus on two different "personas" of cybersecurity architect: the application security architect and the network security architect. There are, of course, other specializations beyond this (data security architects, cloud security architects, and so on) and, usually in smaller or mid-market organizations, you can find those with a focus and goals that span both roles. However, we've chosen these two specializations for a few reasons:
- They are the most common. While there are potentially as many security architect specializations as there are technologies themselves, most cybersecurity security architects' scope will fall into one of these two groups or (like a cloud security architect) potentially span both.
- They represent most tools/techniques that you will encounter. Other specialized sub-disciplines with cybersecurity architecture will likely adapt tools and methods from one of these specializations. For example, a security architect whose focus is on hypervisor deployment in a data center (that is, a "virtualization security architect") might leverage tools and techniques predominantly from the network security architecture world. Those working on securing a container-driven service mesh architecture might primarily use tools from the application security world.
Ultimately, context will dictate which of the tools and techniques we cover will be most useful to you and germane to your role. However, the versatile architect will have a working familiarity with approaches that address both the application and network side of the technology landscape.
The difference between "architecture" and "secure architecture"
Earlier, we learned what a cybersecurity architect does at a very high level. We looked at a very quick skeleton of what tasks are in the security architect's role. Naturally, at this point, you may be anxious to move directly into the "nitty-gritty" of the day-to-day life of a cybersecurity architect. This temptation to start digging into the weeds is natural, but it's better to begin with understanding the why instead of the how. Meaning, understanding why organizations have a specific earmarked position for a cybersecurity architect in the first place.
The fact of the matter is that any organization (including yours) will have a cybersecurity architecture. This is true no matter what you do. Even if you do nothing and completely ignore all principles of sound network design, sound application development, and all requirements and principles, you'll still have a "cybersecurity architecture" – just not a planned, thought-out, and efficient one. Instead, it'll be whatever architecture happens to evolve organically in an ad hoc fashion over time.
Having an architect at the helm of security design means having someone who is ultimately accountable for ensuring that the overall design and vision is efficient and effective. This is particularly important as human nature tends to favor entropy in design (that is, less mature, considered, and planned out).
Important note
This is generally true regardless of context; for example, whether you're talking about writing new software, deploying new commercial off-the-shelf (COTS) applications, building networks, or adopting a new technology (for example, the cloud).
Why does human nature tend to remove focus from planning phases? The reasons why this happens aren't tremendously hard to understand. Let's for the moment imagine a technology project as having three fundamental phases. This is obviously a vast oversimplification for most projects, but bear with me:
- Planning: The process of assessing requirements, marshaling resources to do the work, assigning work to resources, setting key milestones, setting a budget, and so on
- Implementation: Making required investments, setting resources to tasks, writing code, implementing hardware, and taking any other actions you may need to execute
- Maintenance: The continual process of maintaining the solution you've put in place to make sure that it continues to meet the goals over time
Represented visually, this would look something like Figure 1.1:
Figure 1.1 – Generic execution process
Now, of these three phases, into which bucket does the attention of those doing the work tend to go? Stage 2 (implementation), right? Any new project represents an area of need for the organization. After all, if there's no need to do a project, why would they undertake it in the first place? When there's a need, there is pressure to address it. Often, stakeholders will apply pressure to actually make progress and sometimes view planning phases as "delay" that is gating the organization from getting to a solution, implementing a fix, or addressing the need. The point being, there is often pressure within organizations to minimize the time spent planning.
On the other side, something similar happens with the maintenance and support aspects of the project. Here, there's a similar tendency to de-emphasize maintenance implications and considerations relative to implementation. There can often be a we'll cross that bridge when we come to it mentality where the focus is on getting the solution to work in the first place (closing the area of need) while leaving the work of sorting out the support and maintenance details until after the immediate pressure to address the need is met.
The point of all this is that most people (and most organizations) naturally feel pressure to move directly to the implementation of a project. This doesn't mean that nobody ever plans – just that there can be pressure to minimize or de-emphasize non-implementation steps relative to implementation-focused ones. Additionally, as time constraints and real-world business needs drive planning cycles to be more modular, it can become harder and harder to see the "big picture."
The benefits of building secure, resilient architectures
All of this highlights why, in a given project, human nature and business pressure work against some of the planning elements of the design. But who cares? Will an implementation that has evolved ad hoc, piecemeal, and organically be substantively worse in every case? No. It does mean though that it can be more difficult to optimize over the long term than a more planned, systematic approach.
To illustrate why this is the case, consider another analogy, city planning. Most of us know that there are "planned" and "unplanned" cities. Planned cities are those where traffic, zoning, roads, and other aspects are based on human design. Unplanned cities are those that developed organically over time based in large part on the actions of the people living in it. Consider then the experience of driving (and navigating) through a planned city (for example, the Manhattan borough of New York City, Chandigarh, or Dubai) compared to an unplanned one (for example, Boston, London, or Chennai). The planned city might use a "grid" or "ring" approach, while the unplanned city uses road patterns that evolved over time. For most non-native inhabitants, the planned city is easier to navigate: while they won't know exactly what's on a given road, they will know what direction the road leads in (and likely what other roads it intersects with) based on the planned design.
There are likewise benefits from a planned, structured approach in technology projects. Technology projects that are developed and fielded in a systematic way – where detailed attention is paid to the goals of the project, and where future-proofing and subsequent improvements that might be made down the road are accounted for – can have direct performance, operational, or maintenance (supportability) benefits right from the get-go. Likewise, future adjustments to the design or the incorporation of new components/technologies into the mix can be, in many cases, more effectively deployed when existing elements are laid out in a structured, organized way.
The point? The technology architect is responsible for coming up with the organizing principles that will be used for the project in scope to achieve this organized, planned result. In the case of a network architect, this means coming up with a design for the network that enables reliable, fast, and secure communications today and that can be most easily extended and upgraded tomorrow. In the case of the application architect, it is the same: they're responsible for coming up with application designs that meet the requirements of users today but that can also easily be updated with new features should the need arise.
In the context of the cybersecurity architect, the same principles apply. The goal in this case though is to create a model and design for security that fulfills today's security needs but that can also be easily extended when new features are needed, when the business context changes, or in any situation where adjustments need to be made to accommodate future activity.
The role of the architect
The architect then is there to help make sure that technology projects fit into an integrated strategy. An architect comes up with a "vision" for the solution that guides the entire life cycle. Just like an architect working in the physical world on a building or bridge, the technology architect evaluates goals and constraints – things such as the goals and envisioned purpose, support and maintenance requirements, integration with existing technology, the strategic direction of the organization, and budget and resource requirements – to come up with an overarching design that makes the most sense for the organization. Once the architect has a vision in mind, they come up with a blueprint for how to execute that vision.
This is of course true about any architecture discipline within technology. Application architects, for example, develop and maintain a master vision of one or more applications; they make sure that new software (components, extensions, new features) fit well within the existing ecosystem and are consistent with the direction that the organization is looking to go in with their application portfolio. Likewise, network architects have a vision for connectivity. They create and maintain a master vision of the overall network, ensuring that new devices, new services, and so on fit efficiently and optimally within the larger framework so that service is maximized, and things keep running as smoothly as possible.
Cybersecurity architecture is no different. In a nutshell, security architecture is the process of ensuring the following:
- The approach to security within the organization is well planned.
- Resources are used optimally.
- The goals of the organization (both security as well as business and functional goals) are met throughout.
- There are measures in place that allow future growth and expansion.
A security architect generally develops and maintains a vision of security for the technology elements and components within their scope. The more specialized network security architect is responsible for ensuring the design and execution of the security elements that apply to the network while application security architects do so for the security of applications that may be under development. For each, their role is there to ensure that new work in security is performed optimally, that security goals are met, that deployment is efficient, and that the design of new security services advances rather than impedes the overall direction that the organization is trying to go toward.
The scope of the security architect can be narrow or specific. They might be responsible for one or more applications, for a network or set of networks, or for the security controls and services within a business unit or the entire organization. A cybersecurity architect in one organization might be responsible for infrastructure controls such as firewalls, anti-malware, and an intrusion detection system (IDS), whereas the cybersecurity architect at another firm might work hand in hand with developers to ensure that the security needs of a given product or application are met. Yet another organization might have both sets of security architects, each focusing on their particular area. The specific context within which the security architect operates will govern their areas of focus.
Secure network architectures
The role of the cybersecurity architect is, as we've discussed, chief planner and vision-keeper for security within the organization. As mentioned though, there are different types of security architects. One of the primary areas where cybersecurity architects will play a role is in the creation, design, execution, and operation of the secure networking and communications infrastructure of the organization.
Historically, most organizations (from the largest to the smallest) of necessity were directly responsible for maintaining their own robust network. The network served as the primary communications medium for employee collaboration (through services such as email, file sharing, collaboration tools, intranet portals, and numerous other avenues of communication) but they also had another role too: the substrate upon which internal business applications were deployed. Meaning, in addition to providing internal communication services (a valuable end in and of itself), the internal network also historically played a significant role in enabling business applications that make the organization run.
The astute reader might wonder the rationale for the repeated use of the word historically in laying out the preceding. This is due to the fact that, for many organizations, the functional role of the network itself is in a period of transition. Specifically, while the network is still very much the primary conduit for employee communication, some of the use of the network as the "launchpad" for internal services has migrated off the internal network to the cloud. This isn't to say that all internal business applications are now cloud-based; after all, there will always be specialized applications (industrial control networks, biomedical applications, and other specialized hardware/software) that either can't go to the cloud or, for security or functional purposes, it would be foolhardy to relocate there. But for many organizations that don't have these specific requirements, much of what would have been fielded to an on-premises data center, to communicate over internal network channels, has been relocated to cloud environments.
Despite this, the network is critical to the way that business gets done in modern organizations. Not only are there still (despite the cloud migration we alluded to) internal applications that employees need access to, but there are also communication and collaboration tools that they need to use and that require network connectivity for them to reach. There is also an increasing array of mobile and cloud services that require internet access to reach them. Employees, business partners, guests, and others therefore rely on the network for everything from checking their email, sharing documents and files, accessing cloud services and internal applications, conducting telephone calls (for example, via VOIP), and the numerous other activities involved in doing their jobs.
The role of the security architect in a networking context is to ensure three primary goals: confidentiality, integrity, and availability (CIA). Those familiar with security will likely recognize these fundamental concepts given how critical they are to the discipline of security. However, applying these concepts from a network architecture point of view also means accounting for three other factors across multiple dimensions: "effectiveness," "resiliency," and "depth." "Effectiveness" is very straightforward: are the security measures effective at doing what they need to do in enforcing the CIA goals? The last two require a little bit more explanation. Specifically, by "resiliency" here we mean not that the network itself is resilient (this falls under the existing pillar of availability in the CIA triad) but instead that the mechanisms that enforce those goals are resilient against disruption. Likewise, by "depth" we mean that the mechanisms need to apply at multiple levels of the network stack.
Throughout this subsection, we'll walk through each of these areas in detail. We'll talk about CIA in general for those that might be unfamiliar with these concepts and then will talk about resiliency and depth of coverage. We won't get into the "how to" (yet) of building a secure design, but instead just want to outline the specific requirements of what a secure design would entail in the first place.
CIA
The most critical underlying principle to secure network design is to ensure that the network facilitates the security goals of the organization more generally. These will likely be organization-specific to a large degree, but when examined from the highest "altitude" (that is, at their most abstract) will likely generally align with the tenets of the "CIA triad," pictured here:
Figure 1.2 – The "CIA" triad
For those that have some familiarity with the principles of cybersecurity under their belt, they will almost certainly recognize this acronym. For those that do not, it refers to the three core tenets of security:
- Confidentiality: The property that information is only disclosed to those that are authorized. Meaning, data is confidential to all those without a legitimate business need to know.
- Integrity: The property that information is reliable: it cannot be changed or modified unless performed by someone who is authorized to make that change.
- Availability: The property that resources and information can be accessed when needed.
Each of these elements is important from a network design perspective. Confidentiality is important because the design of the network should mean that conversations between parties who may need to exchange data that needs to be kept confidential should have away to do so. There are numerous strategies for accomplishing this: the use of encrypted network protocols (SSH, TLS, IPsec, S-MAIL, and so on), network segmentation (that is, creating sequestered network zones where those not on the same VLAN, segment, and so on can eavesdrop on cleartext traffic), the tunneling of insecure ports over secure protocols, as well as dozens of other strategies.
Likewise, integrity – the capability to ensure data quality from deliberate tampering or accidental degradation – can also be facilitated at the network level. There are protocols that can help enforce integrity during transmission, applications and hardware that can enforce it during storage, and strategies such as blockchain that can enforce it against deliberate attack. Once again, even internal segmentation can help drive integrity goals as fewer individuals with access to data, files, or other artifacts results in correspondingly fewer people who can manipulate them in undesired or unauthorized ways.
Lastly, availability. Availability just means that the services that people need to use are available for use when needed. As a practical matter, natural and man-made disasters can impact availability – for example, when data links are down – as can human agents (for example, denial of service attacks against the network). Just as there are both design strategies and countermeasures that foster confidentiality and integrity, so too can both strategies help with availability. Tools such as DDoS prevention can help mitigate certain types of attacks, whereas high availability, redundancy, and load balancing strategies can be incorporated into the design to help with natural or man-made disasters.
The point of all this is that it is the job of the network security architect to create designs that account for and preserve each of these properties. More specifically, it is the job of the security architect to understand which of these tenets apply in a given situation based on the business needs and what the relative priority of a given tenet is based on context and requirements, and to craft solutions that address them appropriately given that information.
Designing for "resilience"
One of the primary considerations for the network security architect is designing the network to be resilient. We're referring to the ability of resources to remain available and protected despite unexpected events, natural and man-made disasters, attacker activity, and any other unforeseen situation. "Resources" in this context refers to anything and everything employees or the business needs to accomplish the organization's mission: everything from the ability to conduct conference or voice calls, to remote working and telepresence, to email and other messaging tools, to internal or external business applications. Even something simple such as access to files or the ability to call a coworker can be a "resource" in this context.
It is an important property of availability that the network is designed such that it continues to operate and provide the right access to the right people even in adverse situations (such as a pandemic, flood, earthquake, or communications disruption). The way that this is actually done must, out of necessity, change somewhat depending on specifically what might impact the network and how. For example, ensuring access to services during a natural disaster (something such as a flood or inclement weather) is a very different proposition – using different tools and technical strategies – compared to a situation instigated by human action (such as a human attacker).
However, there is more to the resilience design aspect than just these availability concerns (important though they are). Specifically, it is also important that the mechanisms that enforce CIA are themselves resilient against disruption. For example, should a major catastrophe happen, confidential data is kept confidential, data remains trustworthy, and services remain available. By analogy, think of a bank. Would it make sense to design a vault that would unlock itself and open the door if the fire alarm is pulled? No, right? Even if there is a fire (or threat of fire), we still want to keep the assets protected.
With this in mind, there are a few different individual goals when it comes to the overall design of both the network as well as the security mechanisms used by the network:
- High availability: Ensuring network-based services and tools remain available during natural and/or man-made disasters such as earthquakes, floods, fires, or pandemics
- Resistance to attack: The degree to which network countermeasures mitigate or thwart attacks by human or software threat agents
A secure network design therefore will enable both goals. In the case that the architect has direct input into the design of a new network, the security architect will work directly with the engineers and other network architects to make sure that these properties are "baked in" to the overall network design; in situations where the network already exists (in many cases, designed and built without these goals in mind or with minimal focus on security), they will work with other stakeholders to build out a portfolio of countermeasures and improvements that help to increase resiliency after the fact.
"Depth" of coverage – securing the stack
The last dimension for the network security architect is the need to address security at all layers of the network stack. Meaning, security shouldn't just apply to a subset of the network, but instead to all levels.
One of the most powerful conceptual tools in the IT world is the networking stack. Most technology practitioners have some familiarity with either the OSI or TCP/IP stacks. OSI (Figure 1.3) divides networking communications into seven layers (application, presentation, session, transport, network, data link, and physical):
Figure 1.3 – The OSI model
The TCP/IP model (Figure 1.4) divides it into four layers (application, transport, internet, and link layers):
Figure 1.4 – The TCP/IP model
As you can see, each layer of the stack comprises specific technologies, protocols, software bindings, and other artifacts that accomplish a particular aspect of delivering data between nodes on a network. For example, protocols that encode individual bits as electrical signals on a wire or as individual pulses of light on an optical fiber are defined in layer 1 of both models (the physical and network access layer in the OSI and TCP/IP model respectively). Protocols that group together individual bits into more complex structures (frames and packets, for example) occur higher up in the stack, and protocols responsible for delivery of those packets to destinations outside the current local network are higher up still.
The point? This network stack concept is powerful because it allows a technology professional to deliberately limit or compartmentalize their scope to only a subset of the network rather than needing to weed through tremendous complexity each and every time they need to accomplish a particular task. Meaning, engineers can focus only on one particular layer of the stack at a time; by doing so, they can "compartmentalize" complexities associated with other levels of the stack that aren't relevant to the question they are trying to answer. For example, consider a network administrator looking to understand why traffic is not being read by a given application. They might start by looking to ensure that the network is routing traffic correctly to the destination – looking at the IP protocol at layer 3 of the OSI stack. From there, they can either diagnose and debug the problem or, if they are unable to solve the problem by looking at layer 3 in isolation, expand their analysis to include other layers and consider them each in isolation until they do.
The fact that the network stack is organized in this way adds both complexity as well as opportunity for the network cybersecurity architect. It adds complexity because the architect is responsible for all levels of the stack and therefore needs to account for all of them in their vision. This means that they need to factor all levels of the stack and how they are implemented in the organization into their planning; it also means that they need to select and apply appropriate security countermeasures in that plan. This adds complexity because, as anyone who's looked at traffic on the network can tell you, there's a lot of surface area when considering all layers of the stack. The fact that the architect's role is so all-encompassing though also means that countermeasures they put in can either span multiple levels of the stack or target a different area of the stack other than where the problem occurs. For example, a network security architect seeking to address an application issue (layer 7 of the OSI stack) might target another level of the stack to resolve the problem.
As an example of this, consider an application that might not have a facility for strong authentication of users: maybe it requires a username and password but doesn't use a secure channel such as TLS for the transmission of the username and password. Obviously, the ideal strategy is to address this – a layer 7 problem – at layer 7 itself. But what if that's not feasible? Say, for example, that the application is supplied by an external vendor and they are unwilling or unable to close that particular issue. The architect then, knowing that there might not be an optimal layer 7 solution to the issue at hand, might decide to implement a solution at a lower level of the stack. For example, they might consider tunneling the traffic, using filtering rules to ensure that only users from inside a trusted zone can access the service, and so on.
The job of the network cybersecurity architect then is to ensure that the solutions that they create, the network design that they work with other stakeholders to build and hone, and the countermeasures that they deploy protect the network fully and comprehensively – that is, at each level of the stack.
Secure application architectures
From the standpoint of end goals, the remit of the application security architect is like that of the network security architect: ensure the security of the entities in their scope. In this case though, instead of focusing on the infrastructure that helps to enable application delivery, they instead focus on the applications themselves: ensuring that they are built with security in mind, that the process of building them satisfies security goals, that they have appropriate and strong security features built into them to achieve those goals, and so on.
For the application security architect, the specific responsibilities, actions, and – most importantly – goals depend to a large degree on the phase of the development effort that the organization is undertaking. For example, there are different goals and approaches for projects in the following areas:
- Requirements: Outlining and documenting what the scope and purpose of the application are.
- Development: While the software is under active development: namely, the period from ideation to release, either for new software or updates to existing software. Note that this includes any interim, pre-release phases such as unit testing, integration, functional and performance testing, building, and any other phases of the life cycle that may be applicable to a given organization.
- Release: The process of deploying the software to production. This includes the release process itself followed by immediate pre - and post-release actions such as shakeout and production deployment.
- Support: Post-release updates, support, and maintenance.
This section outlines some of the main concerns and goals of the architect during each of these phases. In addition, just like cloud adoption and externalization has "muddied the waters" in the networking space, so too have evolutions in the software development process added complexity to the application space. As organizations and software development methodologies have evolved, the pace of code release has increased.
Important note
The pace of release has accelerated to the point that now, in many organizations, software release is continuous or nearly so. We've seen new "continuous development" models emerge along with DevOps (and DevSecOps) alongside breakneck release timelines; Amazon, for example, has reported that they deploy new production code every second (https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html) while Google reports that they conduct over 4 million builds on the average day (https://thenewstack.io/google-reveals-the-secrets-of-devops/).
While the goals of application-focused security architects are the same in models where the delineation between phases is blurred, it may be a little harder to see clearly; additionally, since some of the tools and techniques associated with the architecture process must, out of necessity, be different in this context, we've elected to include a separate discussion in this section about these models specifically.
Requirements and design
During the earliest stages of planning, the architect is involved in making sure that security requirements are captured, that key features reflect not only important elements of security (for example, authentication, protection of data, data integrity, availability, and so on) but also that "misuse cases" (for example, how the application might be attacked or features subverted) are considered along with the use cases or "user stories" that are used as input in the application design process.
Development
During the period when software is being actively developed, the life of the cybersecurity architect is very busy. At this stage, the architect must create a plan for the application and an overall design that addresses a few different considerations:
- Security functionality: Strategies to ensure that any functional security requirements are addressed securely. This includes features such as user account management, administrator and user authentication, logging and monitoring features, secrets management (for passwords, API tokens, cryptographic keys, and so on), availability considerations, and others.
- Threat mitigation: Strategies to ensure that the application is resilient against attack or accidental misuse. This includes input tampering or over-run, insecure business logic, race conditions, or any other flaw in the software that could allow or facilitate unauthorized activity.
As you might imagine, each of these areas of focus has its own tools and techniques to achieve with optimal effect; we will discuss some of these tools and techniques in more detail in subsequent chapters as we explore the ins and outs of how to create a cybersecurity architecture for an application. For now, though, the important point is that the design phase of an application provides for the architect an optimal time for large, sweeping changes to the security profile of an application.
Software engineer and professor Barry Boehm famously pointed out in Software Engineering Economics, Prentice Hall PTR, that the cost of fixing a software flaw increases non-linearly over time; in other words, that the farther along in the development life cycle a flaw is discovered, the more expensive it becomes to fix. In fact, graphs such as the following one, representing the cost of a software defect over time, are still often informally referred to as "Boehm's Curve" in honor of this insight (Figure 1.5):
Figure 1.5 – Boehm's Curve (or Boehm's Law)
Just like fixing a defect, changes made to the security model of an application are much more easily and cost-effectively addressed earlier in the life cycle than they are later. For example, consider a security defect, for example, a security vulnerability that could undermine a key portion of the application or that could allow an attacker a method to subvert the application. Should a developer find a bug like this immediately after authoring the code that contains it, fixing it is relatively simple: they just modify the offending code, test it, and call it a day.
What happens though if they do not find that bug until much later in the process; say, for example, after they have shipped a million units of that software across the globe? At that point, the complexity – and cost – of applying the fix is comparatively astronomical: the developer still has to update the source code and unit test it the way they always would – but now, they also need to integration test the change against the rest of the product, slot it for a release, rebuild, release a patch, notify users of the issue and get them to patch, and then support the patch application for the host of users it will invariably fail for. This of course assumes that they are able to notify all users in the first place; as we all know quite well, many times they will not, leaving potentially hundreds or thousands of users vulnerable to the issue.
Therefore, not only must the architect design a "vision" for the overall security of the application during the design and development phases, they must work extra hard to ensure that they have thought through how the application will be used, how it might be attacked, any budgetary or resourcing constraints that would be imposed by their design, and they must socialize and gain acceptance for their design (and the changes that design requires) from the engineers actually authoring and developing the software. Just like other features, not every security goal, feature, and countermeasure will ultimately make it into the initial release of the application.
Release
During the release process, security is also an important consideration and goal for the architect. At this point, because of their efforts during the development phase, the architect will ideally have a solid design for the application that is implemented (to a greater or lesser degree) within the application as the organization undertakes fielding it to production. As you might expect, there will likely be some aspects of the security model, vision, and design that will require orchestration during the release process to work and perform optimally.
As an example, consider the situation where the architecture calls for the use of cryptography as part of the application security model and overall design. During the development process, the security architect would work with the development team to create the logic behind this, but reasonable security hygiene obviously would preclude using the same secrets (keys) during development as what will ultimately be fielded into production. Therefore, the process of actually creating those production keys – and storing them in a location where they are themselves appropriately protected – needs to happen during the release process itself.
There are often quite a few tasks like this that will be required when an application enters production. These can include secrets as in the preceding example, but can also include deploying new hardware or software security products, the reconfiguration of existing hardware or software, user training and education, the execution of scripts, or really any other release-related task that the application might require.
The upshot? While during the development phase, the architect will be heavily involved in the planning and design decisions, they may take a more active role as problem-solver, troubleshooter, and even active participant in development.
Support
Once the application is released, the focus of the architect shifts once again. In fact, this is where the work gets the most interesting for the architect, as there are multiple areas of focus that they must maintain simultaneously. These are as follows:
- Execute the long-term vision.
- Respond to unanticipated behaviors of the application in the field.
- Participate in the design of future iterations of the application.
As we mentioned during the preceding discussion, it is highly likely that some of the security features, along with countermeasures required to keep the application secure, may not make it into the first release. This can be because those features would require slowing down the release to implement fully in time for a scheduled deployment, because they are dependent on application functionality that itself is scheduled for a subsequent future release, or any other reason. In fact, it is almost certain that there will be something that will need to be addressed in future iterations. Working with other stakeholders, the security architect will need to continue to work to get these deployed over the long term.
In addition, just like there are "hiccups" in new applications, so too can there be unexpected events that arise in security features and security controls. As part of the support process, the architect will need to be involved in ironing those out. These can be bugs in security features that are intrinsic to the application, they can be emergent behavior that can only be seen once the application usage reaches a certain scale, or they can be bugs or unexpected behavior in security products, tools, or countermeasures that were deployed to support the application.
Lastly, don't forget that it's a rare application that has one release and doesn't ever get updated subsequently. Meaning, it's almost certain that as an application enters the support phase for a given release, the next release will almost certainly be entering (or have already entered) the design and development stages for new features. So, just like the architect needed to plan security features and protections around the initial release, so too will subsequent releases bring with them modifications and necessary changes that the architect will need to be involved in.
Building security in
Now, you may notice that in looking through the lens of these phases, the specific goals and tasks of the architect are clear at each phase when laid out in this way. You can likewise probably realize how and why the architect changes their approach and focus somewhat on the portion of the cycle that they are in. But the truth is that it is more complex than it seems based on just looking at these discrete, monolithic phases; because most new software being built in enterprises today no longer uses such clearly defined phases. Instead, the lines between phases have blurred – or in some cases disappeared entirely.
In other words, under legacy models such as waterfall, development phases were closer to clearly defined, boundary-aligned steps with clear gates between stages ultimately leading to a developed project. It was never perfect even under waterfall, as some phases (for example, testing) were always iterative in nature and not a one-shot, monolithic process. However, newer models have less clear differentiation than even that. For example, DevOps blurs the lines between "development, release, and support" and approaches such as CI/CD (continuous integration and continuous development) mean that each portion of the cycle may be so compressed as to be almost meaningless.
What's important to note about this is that the goals of the architect – and the scope of what they are called upon to do – don't really change even when the development models don't have clearly defined phases. We describe them as done precedingly for the purposes of illustrating the focus and key aspects of the architectural role in each area, but ultimately, the architect is still focused on developing a clear vision (of the application's security profile, security features, use and misuse cases, and how it might be attacked) for the application regardless of the underlying model used to author and deploy it.
One additional substantive part of the architect's job that models such as DevOps and CI/CD can help illustrate is the role of architecture in the development methodology and release process itself. Meaning, architects often have a stake in how software gets developed in the first place. This means that they can have a role in ensuring a process that fosters reliable, consistent, and secure outcomes. Under a waterfall model, this might mean that they incorporate security design reviews, manual or automated software security testing, code review, or other checkpoints or gates into the release process. Under agile, it might mean that sprint reviews include time to specifically discuss and evaluate security topics and features. Under DevOps, it might mean an automated security testing capability integrated into the pipeline. In all cases, it also likely means a culture built around security: by training developers on security coding techniques, by supplying components (for example, cryptographic modules, authentication components, services, or other software) to encapsulate and provide security functionality, or numerous other techniques.
The distinction between "what is built" and "how it's built" is subtle, but the outcomes of each are clearly inter-related. Aldous Huxley, in Ends and Means: An Inquiry into the Nature of Ideals, Routledge, once famously said that "The end cannot justify the means, for the simple and obvious reason that the means employed determine the nature of the ends produced." By this, he meant that the way that you derive something ultimately dictates what the result will be. In the context of software development, this means that if you follow a slapdash, disorganized process, then you will tend to wind up with a slapdash, disorganized result – a result that is more likely to have vulnerabilities, security flaws, weaknesses, and other undesirable security properties.
If instead, you follow a process that engenders security – where security is accounted for and actively espoused during the development process – the resulting software will tend to be more resilient than would otherwise be the case. Therefore, ensuring that the end result is secure requires an effort to "build security in" to the software development life cycle. The tools, techniques, and processes to do this will vary from organization to organization depending on their culture and context; this means that, for organizations where this is a goal, it is often the remit of the security architect to create a vision for those mechanisms to the same degree that they are responsible for ensuring the security of the software itself.
