Application Security Architecture

By Saeedeh Zeinali

v 1.0
Outline
What is software architecture?

What is software design?

What problems does architecture analysis solve?

Building Secure Architectures

A Secure Systems Development Methodology

Patterns for Identity Management

Patterns for Authentication

Patterns for Access Control

 What is software
architecture?
The software architecture of a system depicts the system’s organization or structure, and
provides an explanation of how it behaves. A system represents the collection of
components that accomplish a specific function or set of functions. In other words, the
software architecture provides a sturdy foundation on which software can be built.

1
 What is software
design?
Software design is the process of conceptualizing the software requirements into software
implementation.

Software requirements specification High-level design Detailed design

This document describes the expected
behavior of the system in the form of
functional and non-functional
requirements.
2
The high-level design breaks the system’s Detailed design involves the
architectural design into a less-abstracted implementation of what is visible as a
view of sub-systems and modules and system and its sub-systems in a high-
depicts their interaction with each other. level design.
 What problems does
architecture analysis
solve?

Analyze fundamental design principles Assess the attack surface Enumerate various threat agents Identify weaknesses and gaps in security controls

Architecture risk analysis Threat Modeling Security Control Design Analysis

3
 Building Secure
Architectures
Design in art, is a recognition of the relation between various things, various elements in the creative flux. You can’t invent a design. You recognize it, in
the fourth dimension. That is, with your blood and your bones, as well as with your eyes.

Enumerating The Analysis The Design

Threats Stage Stage
An important aspect of A semantic analysis We can now carry over the
security requirements is a pattern is a pattern that security architecture of the
systematic and accurate describes a small set of analysis stage to the
listing of the potential coherent use cases that design stage.
attacks (threats) to the together describe a basic
system. generic application.

4
 Building Secure
Architectures
Enumerating Threats

Use cases for a financial institution Activity diagram for the use case ‘Open an account’
5
 Building Secure
Architectures
The Analysis Stage

Sequence diagram for the use case ‘Admit a new patient’ PATIENT TREATMENT RECORDS pattern with RBAC authorizations

6
 Building Secure
Architectures
The Design Stage

Adding security enforcement through interfaces

7
 Explain the value of the pain you alleviate

A Secure Systems Development

or the value of the pleasure you provide.
Kindly delete this note after editing this page.

Methodology
As a possible approach to simplifying the use of patterns by designers, we can define
extended patterns that include more information about their use

Secure semantic analysis patterns (SSAPs) Enterprise security patterns (ESPs) Tags

In this approach a SAP is made secure by
adding security patterns after analyzing its use
cases and its possible threats. A SAP is a
pattern combining a set of basic use cases. For
example, we produced a set of secure functions
for law firms.
An enterprise security pattern combines a wide Tags include the security objective, the pattern
range of items describing generic enterprise applicability, trade-off labels (impact on other
security architectures that protect a set of concerns) and relationships between patterns.
information assets in a specific context. They
are a more comprehensive type of pattern that
can handle more threats, to facilitate the
selection and tailoring of security policies,
patterns, mechanisms and technologies for
designers when building enterprise security
architectures.

8
 A Lifecyle-Based
Methodology
A better approach is extending a development process to incorporate security in all the stages of
the lifecycle

From the requirements stage we generate secure use cases.

From the analysis stage we generate authorization rules that

apply to the conceptual model.
From the design stage we enforce rules through the
architecture.

In the implementation, deployment and maintenance stages,

language enforcement of the countermeasures and rules is
required. Security verification and testing occurs at every
stage of development. We describe the details of each stage
below.

9
 A Lifecyle-Based
Methodology
A better approach is extending a development process to incorporate security in all the stages of
the lifecycle

Requirements stage. Use cases define the required

interactions with the system. Applying the principle that
security must start from the highest levels, it makes sense to
relate attacks to use cases and develop what we call secure
use cases

Analysis stage. Analysis patterns, and in particular semantic

analysis patterns, can be used to build the conceptual model
in a more reliable and efficient way

Design stage. We express the abstract security patterns

identified in the analysis stage in the design artifacts; for
example interfaces, components, distribution and
networking.

10
 A Lifecyle-Based
Methodology

Typical attacks to the layers of a system

11
 Using Model-Driven Engineering
Metamodels describe sets of related concepts that are instantiated together (maybe partially) as part of a
methodology or procedure to design a system. The UML class diagrams that describe the solutions of patterns are
metamodels that are instantiated to apply security, reliability or some other property to the functional aspects of
an application.

12
 Patterns for Identity Management
A user may not be known in advance by the resource manager at the time of the request, and consequently their
identity may need to be transmitted to the resource’s domain. Traditional models don’t address the dynamic
aspects of identity management.

The IDENTITY PROVIDER pattern

centralizes the administration of a security
domain’s users, creating and managing
identities for their credentials.

The CIRCLE OF TRUST pattern represents a

federation of service providers that share
trust relationships.

The IDENTITY FEDERATION pattern allows the

federation of multiple identities across multiple
organizations under a common identity. In web
services environments, this pattern relies on the
SAML ASSERTION pattern, which provides a unifying
format for communicating identity information
between different security domains.
13
 Patterns for Identity Management
The CIRCLE OF TRUST pattern allows the formation of trust relationships among service providers to allow their
subjects to access an integrated and more secure environment.

Example
Our university had different ways to access different services. For each service, one needed a different protocol
and to remember a different password. This was cumbersome and prone to error; it was also insecure, because
people would write their multiple passwords on their office bulletin boards.

Problem
In such large open environments, subjects are typically registered (have accounts) with unrelated services.
Subjects may have no relationships with many other services available in the open environment. It may be
cumbersome for the subject to deal with multiple accounts, and it may not be secure to build new relationships
with other services, since identity theft or violation of privacy can be performed by rogue services.

Solution
Each service provider establishes business relationships with a set of other service providers. These
relationships are materialized by the existence of operational and possibly business agreements between
services. Such relationships are trust relationships, since each service provider expects the other to behave
according to the operating agreements.
14
 Patterns for Authentication
Identification and authentication (I&A) uses some kind of protocol to establish identity. I&A is the basis for
authorization and for logging: it provides accountability. Once identity is verified, the system may provide a proof
of authentication to avoid further authentications.

REMOTE AUTHENTICATOR/AUTHORIZER
and CREDENTIAL. CREDENTIALs may have
also authorization properties, discussed
later. In distributed systems where users
may have access to several systems a
Single Sign On service is very convenient

REMOTE AUTHENTICATOR/AUTHORIZER and

CREDENTIAL have dual purposes; they can also be
used for authorization if they include user rights.

15
 Patterns for Authentication
When a subject identifies itself to the system, the AUTHENTICATOR pattern allows verification that the subject
intending to access the system is who or what it claims to be.

Example
The computer system at Melmac State University has legitimate users who use it to host their files. However,
there is no way to ensure that a user who is logged in is a legitimate user. When Melmac was a small school and
everybody knew everybody, this was acceptable and convenient. Now the school is bigger and there are many
students, faculty members and employees who use the system. Some incidents have occurred in which users
impersonated others and gained illegal access to their files.

Problem
How can we prevent imposters from accessing our system? A malicious attacker could try to impersonate a
legitimate user to gain access to their resources. This could be particularly serious if the user impersonated has a
high level of privilege. How do we verify that a user intending to access the system is legitimate?

Solution
Use a single point of access to receive the interactions of a subject with the system and apply a protocol to verify
the identity of the subject. The protocol used may be simple or complex, depending on the needs of the
application.

16
 Patterns for Access Control
Once a subject has been granted access to a system, we need to control their access to specific resources. The
rights of the subjects of the system are defined using some model of access control and expressed in the form
of authorization rules.

An Access Matrix describes access by

subjects (actors, entities) to protected
objects (data/resources) in specific ways
(access types) [Gol06] [Har76] [Sum97]. I

Role-Based Access Control (RBAC) collects users into

roles based on their tasks or functions and assigns
rights to each role [San96].

Attribute-Based Access Control (ABAC). This model

controls access based on properties (attributes) of
subjects or objects.

The Multilevel Model organizes data using security

levels. This model is usually implemented as a
mandatory model in which its entities are labeled
17 indicating their levels.
 Authorization
The AUTHORIZATION pattern describes who is authorized to access specific resources in a system, in an
environment in which we have resources whose access needs to be controlled. The model indicates, for each
active subject, which resources the subject can access and what it can do with them.

Example
In a medical information system we keep sensitive information about patients. Unrestricted disclosure of this
data would violate the privacy of the patients, while unrestricted modification could jeopardize their health.

Problem
We need a way to control access to resources, otherwise any active entity (user, process) could access any
resource and we could have confidentiality and integrity problems, as well as misuse of network bandwidth or
peripheral devices.

Solution
Indicate, for each active subject that can access resources – objects or protection objects – which resources it
can access and how (access type).

18