Security

EXAMPLE: Security is clearly a vital aspect of most architectures. It has always been
important to be able to restrict access to data or functionality to appropriate classes of
users, and in the age of the Internet, good external and internal security is even more
important. If some of your systems are exposed to the wider world, they are vulnerable to
attack, and the consequences of a breach can be disastrous for finances or public relations.
(The large number of high-profile Internet security failures in Europe and North America
during the early part of the millennium illustrates this clearly.)

In our experience, security is often not thought through properly early in the project
lifecycle. Part of the reason for this is that security is hard—the means for achieving an
appropriate level of security are complex and require sophisticated analysis. Also, it may
be considered to be “someone else’s problem”—the responsibility of a specialist security
group rather than of the organization as a whole. You may be surprised, therefore, that we
have not included a Security viewpoint in our catalog to go along with the others
(Functional, Information, Deployment, and so forth). We used to approach concerns like
security just like that ourselves.

We used a Security viewpoint and started to consider which classes of stakeholders have
concerns in this area, what this viewpoint should consist of, and how a typical Security
view might actually look.

However, experience taught us that security is an important factor that affects aspects of
the architecture addressed by most if not all of the other viewpoints we presented in
Chapter 3. Furthermore, which of the system’s security qualities are significant depends on
which viewpoint we are considering. Here are some examples.

 From the Functional viewpoint, the system needs the ability to identify and
authenticate its users (internal and external, human and mechanical). Security
processes should be effective but unobtrusive, and any external processes exposed
to the outside world need to be resilient to attack.
 From the Information viewpoint, the system must be able to control different classes
of access to information (read, insert, update, delete). The system may need to apply
these controls at varying levels of granularity (e.g., defining object-level security
within a database).
 From the Operational viewpoint, the system must be able to maintain and distribute
secret information (e.g., keys and passwords) and must be up-to-date with the latest
security updates and patches.

When we consider the system from the Development, Concurrency, and Deployment
viewpoints, we’ll probably also find aspects of the architecture that will be affected by
security needs.
So our overall criterion of “the system must be secure” actually breaks down across the
viewpoints into a number of more specific criteria .
Going back to our example of security, having decided on a candidate architecture for your
system and captured it as a set of views, you would then apply the Security perspective in order
to ensure that the system meets its security requirements.
To apply this perspective, you would perform a number of activities, as listed in the
perspective’s definition, such as identifying the sensitive resources in the system, identifying the
threats that the system faces, and deciding how to mitigate each threat by using suitable security
processes and technology. The result would typically be some changes to your candidate
architecture such as those listed here.
 You might decide to partition the system differently in order to easily restrict access to
parts of it. This would affect your Functional view.
 Your security design might introduce new hardware and software elements to the system
to limit access or to add additional guarantees (such as encryption to ensure privacy).
You would need to add these new elements to your Deployment view to define where
they fit, and you might need to update the Development view to define how these new
elements should be used.
 You might identify new operational procedures to support secure operation (e.g.,
certificate management) or modify existing procedures to ensure security (e.g., handling
backups of sensitive data). These procedural changes will modify the Operational view.
Applying the Security perspective has not resulted in a new security view but has identified
a number of modifications to your existing views that help address your stakeholder’s
security concerns.

Applying the Security perspective might reveal the existence of a number of significant
security threats that are not countered by the system in its current form. You would then
need to understand these threats, understand what the risks are, and understand the impact
these risks have on your architecture.

Performance and Scalability

Applying the Performance and Scalability perspective to your Deployment view might
demonstrate that you need to replicate the application servers in order to be capable of
scaling to meet expected demand. This could lead to a change to the Deployment model to
show several servers instead of one and possible changes to the Functional or Information
views to support this load balancing

Availability
Consider a self-service banking system that allows users to manage their bank accounts at
automated teller machines (ATMs). The ATM communicates in real time with a central
computer that maintains information on the customers’ accounts. Full service implies that
customers can query balances and enter all supported types of transactions, and no service
means that no inquiries or transactions can be done. From time to time, the communications
network between the ATM and the host computer may fail, may be switched off for
maintenance, or may suffer from poor response due to heavy usage. When the network is
unavailable or unresponsive, local processing could be carried out on the ATM without
reference to the host, allowing the system to offer partial services, such as:
- Restricting users to balance inquiries only
_ Restricting transactions to those below a certain limit
_ Requiring increased time to carry out transactions
_ Restricting users to deposits only