Transcript You can the slides here.

Secure Systems
Requirements and
Construction with Security
Patterns
Eduardo B. Fernandez
Dept. of Computer Science and Engineering
Florida Atlantic University
Boca Raton, FL, USA
http://www.cse.fau.edu/~ed
[email protected]
Secure Systems Research Group - FAU
Abstract
•
Patterns combine experience and good practices to develop basic models that can be used
to build new systems and to evaluate existing systems. Security patterns join the extensive
knowledge accumulated about security with the structure provided by patterns to provide
guidelines for secure system requirements, design, and evaluation. We consider the
structure and purpose of security patterns, show a variety of security patterns, and illustrate
their use in the construction of secure systems. These patterns include among others
Authentication, Authorization/Access Control, Firewalls, Secure Broker, Web Services
Security, and Cloud Security. We have built a catalog of over 100 security patterns. We
introduce Abstract Security patterns (ASPs) which are used in the requirements and
analysis stages. We complement these patterns with misuse patterns, which describe how
an attack is performed from the point of view of the attacker and how it can be stopped. We
integrate patterns in the form of security reference architectures. We introduce patterns in a
conceptual way, relating them to their purposes and to the functional parts of the
architecture. Example architectures include a financial system and a cloud computing
system. The use of patterns can provide a holistic view of security, which is a fundamental
principle to build secure systems. The patterns and reference architectures are shown using
UML models and examples are taken from my two books on security patterns as well as
from my recent publications. The patterns are put in context; that is, we do not present a
disjoint collection of patterns but we present a logical architectural structuring where the
patterns are added where needed. In fact, we present a complete methodology to apply the
patterns along the system lifecycle.
For this conference we emphasize the early lifecycle stages but also show the effect of the
requirements in the later stages.
Secure Systems Research Group - FAU
About me
• Professor of Computer Science at Florida
Atlantic University, Boca Raton, FL., USA
• At IBM for 8 years (L.A. Scientific Center).
• Wrote the first book on database security
(Addison-Wesley, 1981).
• Author of many research papers
• Consultant to IBM, Siemens, Lucent,…
• MS EE Purdue U, PhD CS UCLA
Secure Systems Research Group - FAU
Secure Systems Research Group - FAU
Secure Systems Research Group - FAU
Secure Systems Research Group - FAU
Outline
•
•
•
•
•
•
•
•
•
•
•
•
•
Security concepts
Threats
Approaches to security
The design of secure systems
Security patterns
Principles and policies
Using the patterns
Architectural layers and patterns, Abstract security patterns
Security models and their patterns---policies, access matrix, multilevel
models, RBAC
Conceptual models in applications
Operating systems patterns
Network layer patterns
Patterns for web services and cloud computing, misuse patterns
Secure Systems Research Group - FAU
Outline II
•
•
•
•
•
•
•
A methodology for building secure architectures
Defining authorizations from use cases---nonfunctional aspects of
use cases, RBAC and security policies. Security
Logging/Auditing. Authentication.
Security reference architectures (SRAs), a SRA for cloud systems,
a financial SRA
Coordination across levels---mapping of authorizations across
architectural levels: relating threats to use cases.
Secure semantic analysis patterns
Case studies: a financial system, a cloud system
Conclusions---the future
Secure Systems Research Group - FAU
Objectives
• Get a panorama of security patterns and
their use
• Study some specific patterns in detail
• Consider a systematic approach to build
secure systems based on patterns and
UML
Secure Systems Research Group - FAU
Security concepts
• Motivation and Objectives
• Countermeasures
• Security architectures
Secure Systems Research Group - FAU
The value of information
• Individuals and enterprises rely on
information for credit, health,
professional work, business, education,…
• Illegal access (reading or modification) to
information can produce serious problems
• Because of its value, information is a
growing target of attacks
Secure Systems Research Group - FAU
Cost of data breaches
• An attack on Google cost that company
about $500,000 in 2005.
• In a recent study (Ponemon Institute), the
average cost of a data breach for a
company was $3.75 M in 2014, and the
average cost for each stolen or lost record
was $154.
Secure Systems Research Group - FAU
Security is the protection against:
• Unauthorized data disclosure (confidentiality or
secrecy).
• Unauthorized data modification (integrity).
Unauthorized modification of data may result in
inconsistencies or erroneous data. Data
destruction may bring all kinds of losses.
• Loss of availability (Denial of service)—Users or
other systems may prevent the legitimate users
from using their system.
• Lack of accountability—Users should be
responsible for their actions and should not be
able to deny what they have done (nonrepudiation).
Secure Systems Research Group - FAU
The meaning of security
• Security implies providing these
objectives in the presence of attacks
• Security requires technical, managerial,
and physical countermeasures (defenses)
• We only consider technical aspects here
• A related aspect is privacy, a legal and
ethics concern
Secure Systems Research Group - FAU
Countermeasures I
• Identification and Authentication (I&A)—Identification is a
user or system action where the user provides an identity.
Authentication implies some proof that a user or system is
the one he/it claims to be.
• Authorization and Access control (A & A)—Authorization
defines permitted access to resources depending on the
accessor (user, executing process), the resource being
accessed, and the intended use of the resource. Access
control requires some mechanism to enforce authorization
• Logging and Auditing (L&A)—These functions imply
keeping a record (log) of actions that may be relevant for
security and analyzing it later. They can be used to collect
evidence for prosecution (forensics) and to improve the
system by analyzing why the attack succeeded.
Secure Systems Research Group - FAU
Countermeasures II
• Hiding of information—Hiding the
contents of information is usually
performed by the use of cryptography but
steganography is another option. The idea
is to make the information unreadable to
an attacker.
• Intrusion detection—Intrusion Detection
Systems (IDS) alert the system when an
intruder is trying to attack the system.
Secure Systems Research Group - FAU
Basic secure architecture
• Authentication must happen first
• Authorization rules define what is allowed
or not allowed (who can see what and
how)
• Lower architectural levels enforce
authentication and authorization
• Cryptography protects messages in
transit and stored data, and provides nonrepudiation and authentication
• Continuous logging for later auditing
Secure Systems Research Group - FAU
Security environments or contexts
• Early systems were isolated and single
user --few security problems
• Mainframes brought many users but we
knew them (registered)—complexity and
attacks increased
• Distributed systems increased the
problem by scattering the users
Secure Systems Research Group - FAU
Environments II
• The Internet opened up our systems to
unknown users—exponential growth in
attacks
• Wireless devices increase the problem
because of their number and ubiquity
• The widespread use of sensors will make
security even worse
• The cloud brings new problems
Secure Systems Research Group - FAU
Enterprise architectures
External
Users
..
Web browsers
Internet
Production
Internal Users
Web
browsers
Web
servers
Web
Application
Server
Customers
Intranet
Engineering
Secure Systems Research Group - FAU
Threats
• We need to understand the threats to the
system to decide how to defend it
• Excess of security mechanisms results in
loss of performance, extra complexity, and
higher costs
• The objective is to provide an appropriate
defenses according to the value of our
assets
Secure Systems Research Group - FAU
Attacks and defenses
• Generic attacks are realized in two basic ways: by direct
attacks from a person trying to exploit a vulnerability or
flaw in the system, or using malware, software that contains
code that exploits one or more of these flaws
• Security defenses may operate in one or more of three
modes and we need to combine them:
1. Prevent or mitigate an attack. Prevention means
completely stopping the attack while mitigation implies
partial defense or reducing its effects
2. If we cannot stop or mitigate the attack, at least we should
be able to know that an attack is happening, i.e., we should
detect the attack. Detection is also useful to stop an attack
because it can alert other mechanisms to take action
3. After the attack has happened we need to have ways to
recover from its effects and analyze it so we can improve
the system
Secure Systems Research Group - FAU
Types of Threats
•
•
•
•
•
Direct attacks to the operating system
Direct attacks to the database system
Directs attacks to the application
Denial of service
Almost no attacks to the messages in the
network
• Malware: Trojan horses, viruses, worms
• Repudiation
Secure Systems Research Group - FAU
Metalayer
Application
Layer
A
a:A
B
b:B
inference
wrong models
wrong operations
malformed parameters
language attacks
unauthorized data access
viruses, worms
DBMS
Layer
malformed parameters
unauthorized access
OS Layer
directory attacks
process interference
root attacks
address space violation
unauthorized file access
Hardware/
network
Layer
Secure Systems Research Group - FAU
lack of protection,
eavesdropping
network attacks
Approaches to security
• Formal models do not prove security because
they make many assumptions which may not be
true in practice. Also have size limitations.
• Cryptographic methods are effective but only for
specific aspects: system or message
authentication, secure transmission of messages,
storage protection. They cannot stop attacks
based on code or system flaws.
• Code-based methods cannot find all
vulnerabilities because many attacks exploit
system interactions, not code flaws.
• Model-based security can build a strong structure
where parts of the system may be compromised
but the essential parts of the system can be
protected (submarine effect).
Secure Systems Research Group - FAU
Approaches to security
Model checking
and
composability
of systems
Theoretical
Analysis of
Security
Verification
UML/OCL
models
Security
patterns
Model-driven
Security
Code-based
Security
Certification
Vulnerability
analysis
Code
examination
Best practices
Certification
3/25/2016
Secure Systems Research Group - FAU
26
Current situation
• The Internet is an insecure place and
attacks keep occurring
• One of the main reasons is the poor
quality of the software used in systems
and application software
• Software engineering neglected security
for a long time
Secure Systems Research Group - FAU
A possible remedy
• Help designers build secure systems
using a systematic approach
• Provide units of security (packed
solutions to specific problems)
• Build security together with the functional
part of the application
• Use a model-based approach
Secure Systems Research Group - FAU
Security
Patterns
Software
Engineering
Secure Systems Research Group - FAU
Software
Architecture
Security
Security patterns
• Idea
• Anatomy of a pattern
• Classifications
Secure Systems Research Group - FAU
Patterns
• A pattern is a solution to a recurrent
problem in a specific context
• Idea comes from architecture of buildings
(C. Alexander)
• Applied initially to software and then
extended to other domains
• Appeared in 1994 and are increasingly
being accepted by industry
Secure Systems Research Group - FAU
Value
• Reusable solutions, but maybe not
directly, usually require tailoring
• Encapsulate experience and knowledge of
designers (best practices)
• Free of errors after a while
• Need to be catalogued to be useful
• Used as guidelines for design
• Good to evaluate systems and standards
• Useful for teaching
Secure Systems Research Group - FAU
Why security patterns?
• Analysis patterns can be used to build conceptual
models of software, design patterns can be used to
make software more flexible and reusable, and
security patterns can be used to build secure systems,
including hardware or organizational problems.
• Security has had a long trajectory, starting from the
early models of Lampson and Bell/LaPadula in the
early 70s, and resulting in a variety of approaches to
analyze security problems and to design security
mechanisms. It is natural to try to codify this expertise
in the form of patterns.
• Security patterns describe mechanisms to stop some
attacks and apply principles of good design
Secure Systems Research Group - FAU
Value of security patterns
• Can describe security principles (Single
Point of Access) or security mechanisms
(Firewalls)
• Can guide the design and implementation
of the security mechanism itself
• Can guide the use of security mechanisms
in an application (stop specific threats)
• Can help understanding and use of
complex standards (XACML, WiMax)
• Good for teaching security principles and
mechanisms
Secure Systems Research Group - FAU
POSA template (Buschmann)
•
•
•
•
•
•
•
•
•
•
Intent (thumbnail)
Example
Context
Problem and forces
Solution: in words, UML models (static and
dynamic)
Implementation
Example resolved
Known uses
Consequences
See also (related patterns)
Secure Systems Research Group - FAU
Anatomy of a security pattern
• Every pattern starts with a thumbnail of the
problem it solves and a brief description of
how it solves the problem.
• The Packet Filter Firewall filters incoming and
outgoing network traffic in a computer system
based on packet inspection at the IP level.
Secure Systems Research Group - FAU
Context section
• We define the context or environment where the
pattern solution is applicable:
Context
• Computer systems on a local network connected to the
Internet and to other networks with different levels of
trust. A host in a local network receives and sends
traffic to other networks. This traffic has several layers
or levels. The most basic level is the IP level, made up
of packets consisting of headers and bodies
(payloads). The headers include the source and
destination addresses as well as other routing
information, the bodies include the message payloads.
Secure Systems Research Group - FAU
Problem Section I
• Now a generic description of what happens
when we don’t have a good solution: We also
indicate the forces that affect the possible
solution. We may list all attacks that we want
to stop with this solution.
Problem
• Some of the hosts in other networks may try to
attack the local network through their IP-level
payloads. These payloads may include viruses
or application-specific attacks. We need to
identify and block those hosts.
:
Secure Systems Research Group - FAU
Forces
•
•
•
•
•
•
•
We need to communicate with other networks so isolating our network
is not an option. However, we do not want to take a high risk.
The protection mechanism should be able to reflect precisely the
security policies of the institution. A too coarse defense may not be
useful.
Any protection mechanism should be transparent to the users. Users
should not need to perform special actions to be secure.
The cost and overhead of the protection mechanism should be
relatively low or the system may become too expensive to run.
Network administrators deploy and configure a variety of protection
mechanisms; hence it is important to have a clear model of what is
being protected.
The attacks are constantly changing; hence it should be easy to make
changes to the configuration of the protection mechanism.
It may be necessary to log input and/or output requests for auditing
and defense purposes.
Secure Systems Research Group - FAU
Solution section
• The solution section describes the idea of the pattern.
A descriptive figure may help to visualize the solution.
Solution
• A Packet Filter Firewall intercepts all traffic
coming/going from a port P and inspects its packets
(Figure 1). Those coming from or going to untrusted
addresses are rejected. The untrusted addresses are
determined from a set of rules that implement the
security policies of the institution. A client from
another network can only access the Local Host if a
rule exists authorizing traffic from its address. Rules
may be positive (allow traffic from some address) or
negative (block traffic). Additionally, if a request is not
satisfied by any of the Explicit Rules, then a Default
Rule is applied.
Secure Systems Research Group - FAU
Idea of the solution
External Host
request
Packet
Filter
Firewall
Internet
Secure Systems Research Group - FAU
request
Local network
P Local Host
Structure of the solution
ExternalHost
1 requestService *
PFFirewall
* requestService1
address
address
1
RuleBase
addRule
deleteRule
modifyRule
reorderRules
* {ordered}
Rule
in/out
ExplicitRule
Secure Systems Research Group - FAU
LocalHost
DefaultRule
Filtering a client’s request
«actor»
:ExtHost
:Firewall
:RuleBase
:Rule
requestService( )
requestService( )
checkRule
accept
accept
requestService( )
Secure Systems Research Group - FAU
:LocalHost
Implementation section
•
What one should consider when implementating the pattern is the objective of
the next section. This can be a set of general recommendations or a sequence
of what to do to use the pattern. It may include some sample code if
appropriate.
Implementation
• Define an institution policy about network access, classifying sites according
to our trust in them.
• Convert this policy into a set of access rules. This can be done manually, which
may be complex for large systems. An alternative is using an appropriate
commercial product. .
• Note that the idea of a single point of access is virtual, there may be several
physical firewalls deployed at different places. This means it is necessary to
install firewalls at all external boundaries (routers or gateways).
• Write the rules in each firewall. Again, products such as Solsoft and others
automatically propagate the rules to each registered firewall.
• Configure the corresponding firewalls according to standard architectures. A
common deployment architecture is the Demilitarized Zone (DMZ) [Sch06].
Secure Systems Research Group - FAU
Known uses section
• To accept this solution as a pattern we should
find at least three examples of its use in real
systems.
Known Uses
• This architecture can be found in commercial
firewall products such as: ARGuE (Advanced
Research Guard for Experimentation),
OpenBSD Packet Filtering Firewall (the basic
firewall architecture for the Berkeley Software
Distribution system) and the Linux Firewall,
the basic firewall architecture used with the
Linux operating system.
Secure Systems Research Group - FAU
Consequences--advantages
•
The Consequences section indicates the advantages and disadvantages of the
solution embodied in this pattern. The advantages should match the forces in the
Problem section.
Consequences
The Packet Filter Firewall Pattern has the following advantages:
• A firewall transparently filters all the traffic that passes through it, thus lowering
the risk of communicating with potentially hostile networks.
• It is possible to express the institution filtering policies through its filtering rules,
with different levels of protection for different parts of the network.
• It is easy to update the rule set to counter new threats.
• Because it intercepts all requests, a firewall allows systematic logging of incoming
and outgoing messages. Because of this, a firewall facilitates the detection of
possible attacks and helps to hold local users responsible of their actions when
interacting with external networks.
• Low cost, it is included as part of many operating systems and simple network
devices such as routers.
• Good performance. It only needs to look at the headers of IP packets, not at the
complete packet.
• It can be combined with Intrusion Detection Systems (IDS) for greater
effectiveness. In this case, the IDS can tell the firewall to block suspicious traffic.
This can also be useful to control Distributed Denial of Service (DDoS) attacks.
Secure Systems Research Group - FAU
Consequences--disadvantages
•
•
•
•
•
The firewall’s effectiveness and speed may be limited due to its rule
set (order of precedence). Addition of new rules may interfere with
existing rules in the rule set; hence, a careful approach should be
taken in adding and updating access rules.
The firewall can only enforce security policies on traffic that goes
through the firewall. This means that one must make changes to the
network to ensure that there are no other paths into its hosts.
An IP-level firewall cannot stop attacks coming through the higher
levels of the network. For example, a hacker could put malicious
commands or data in header data not used for routing and in the
payload.
Each packet is analyzed independently, which means that it is
necessary to analyze every packet. This may reduce performance.
A packet filter cannot recognize forged addresses (IP spoofing)
because it only examines the header of the IP packet. This can be
corrected (at some extra cost) using Link Layer filtering, where each IP
address is correlated to its hardware address [Fra01].
Secure Systems Research Group - FAU
Related patterns section (See also)
• Finally, we relate our pattern to other known patterns. Those
may be complementary patterns, variations of our pattern, or
extensions of it.
• The Authorization pattern [Fer01] defines the standard security
model for the Packet Filter Firewall Pattern. This pattern is also
a special case of the Single-Point-of-Access [Sch06] and it is
the basis for other, more complex, types of firewalls (described
in the other patterns in this language). The DMZ pattern [Sch06]
defines a way to configure this pattern in a network. This
pattern can also be combined with the Stateful Inspection
Firewall [Sch06].
Secure Systems Research Group - FAU
The design of secure systems
• Security should be applied where the
application semantics is understood
• Security is an all-levels problem
• High-level policies can be mapped to the
lower levels
• We need precise models to guide system
development
3/25/2016
Secure Systems Research Group - FAU
49
Secure Design II
• A unified system is easier to understand:
better design, better administration
• Easier to analyze effect of new hardware
or software
• Apply principles of good design
• Start from principles, policies, and models
• Apply security throughout the lifecycle
3/25/2016
Secure Systems Research Group - FAU
50
Principles of design for security
• Closed system. Anything not explicitly allowed is forbidden.
The policy is applied to application rights and to process
resource access during execution. This policy can be
considered a special case of fail-safe defaults (see below).
• Open design. When the mechanism is subject to public scrutiny
it is easier to find flaws and with time it becomes increasingly
secure. Some of the data used in the security system could be
secret though, e.g., passwords, keys.
• Least privilege—Assign only the necessary rights to perform
functions
• Economy of mechanism. The security mechanisms should be
as simple and small as possible. This makes comprehension,
testing, and analysis easier.
Secure Systems Research Group - FAU
Principles II
• Complete mediation. Every request for access must be
validated.
• Minimal trust. The parts of the system that must be trusted
should be minimal.
• Separation of privilege. Critical actions may need two
independent mechanisms to agree before being performed.
• Least common mechanism. Do not mix security with other
functions.
• Ease of use or transparency. Users must accept the security
system or they will not use it. Security functions must be
transparent or at least easy to use.
• Information hiding and encapsulation. Implementation details
should not be exposed, only a clear, functional interface should
be shown.
Secure Systems Research Group - FAU
Security principles III
• Holistic approach--Cover all architectural levels and
all units
• Highest level—security constraints must be defined
where their semantics are clear and propagated
down
• Defense in depth—have more than one line of
defense
• Separate and compartmentalize (submarine
principle)
• Secure defaults
Secure Systems Research Group - FAU
Secure Systems Research Group - FAU
Policies
• Institution policies
• Security policies
• Example
3/25/2016
Secure Systems Research Group - FAU
55
Need for policies
• The policies of an institution define its
way of accomplishing its objectives
• Security policies define a way to protect
its information applying principles
• Without policies we don’t know what we
should protect
• Policies can be realized by tactics applied
to the system architecture
3/25/2016
Secure Systems Research Group - FAU
56
Some security policies
• Open/closed systems--In a closed system
everything is forbidden unless explicitly allowed
• Need-to-know (Least privilege)-- Give enough
rights to perform duties
• Information belongs to the institution versus
private ownership
• Authorization-- access types, small units of
access
3/25/2016
Secure Systems Research Group - FAU
57
Security policies II
• Obligation—What has to be done before
accessing data
• Separation of duty—Separate critical
functions into parts to be done by different
people or systems
• Content-dependent access control—
Access decision are based on the values of
the data
• Authenticate all transactions—needed for
accountability and access control
3/25/2016
Secure Systems Research Group - FAU
58
Use of policies
• Secure systems must be closed but
sometimes open access to information is
more important, e.g., libraries, data
warehouses, …
• The least privilege principle must be
applied with an appropriate granularity,
many attacks happen because of too
many rights
3/25/2016
Secure Systems Research Group - FAU
59
Example of university policies
• An instructor can look at all the information about
the course he is teaching.
• An instructor can change the grades of the
students in the course he is teaching
• A student may look at her grades in a course she
is taking
• The department head can add/delete course
offerings
• The registrar can add/delete students from
course offerings
• Faculty members can look at information about
themselves
3/25/2016
Secure Systems Research Group - FAU
60
Using the patterns
• Catalogs of patterns are not enough,
designers must be given guidance in their
use
• There are many patterns (growing in
number) and the task of selecting them
gets harder
• A first approach is to classify the patterns
according to some criteria
Secure Systems Research Group - FAU
Pattern diagrams
•
•
•
•
Show relationships between patterns
Nodes are patterns
Links are relationships
Links are labeled with type of dependency
or contribution
• Useful to guide the designer in the
selection of patterns
• Can go in Introduction to a set of patterns,
or in Context, or in See also
Secure Systems Research Group - FAU
Pattern diagram
Address Filtering
Address Filter Firewall
(static packet filter)
Address Filtering
Secure Systems Research Group - FAU
Proxy-Based Firewall
(application level)
Address Filtering
Content-Based Firewall
Stateful Firewall
How to classify security patterns?
• Avgeriou and Zdun classified architectural
patterns using the type of concerns they address,
e.g. Layered Structure, Data Flow, Adaptation,
User Interaction, Distribution.
• Security patterns can be classified according to
type of mechanism, e.g. access control,
authentication,…
• A computer system is a hierarchy of layers,
where the application layer uses the services of
the database and operating system layers, which
in turn, execute on a hardware layer.
• We combine these two classifications
Secure Systems Research Group - FAU
B
A
Metalayer
classes
C
a:A
Application
b:B
objects
layer
c:C
executing
a. m1
b. m2
System layer
c. m3
processes
(OS/DBMS)
Node1
Node2
Distribution
nodes
layer
CPU1
CPU2
CPU3
Hardware
processors
network
Secure Systems Research Group - FAU
Configuration
Protocol
More advanced classifications
• Use a multidimensional matrix
• Dimensions may include: architectural
level, lifecycle stage, concern, type of
pattern, domain,…
• Example: XACML
Secure Systems Research Group - FAU
lifecycle stage:
design
component source:
all
response type:
prevention
Secure Systems Research Group - FAU
architectural level:
distribution
XACML
Access Control
Evaluator
Solution concern:
access control
constraint level:
mechanism
domain:
SOA, e-commerce
Layers pattern
• Its main idea is the decomposition of a system into
hierarchical layers of abstraction, where the higher levels
use the services of the lower levels.
• We saw two examples earlier
• Some of the layers shown can be further decomposed into
sub-layers or the decomposition can be done along slightly
different aspects, e.g., emphasizing the DBMS
• Among the advantages of the Layers pattern we have the
flexibility to make changes to the lower levels without
affecting the higher levels and the possibility of hiding
sensitive aspects of the system
• Among its disadvantages we have the extra overhead due
to indirection.
Secure Systems Research Group - FAU
Security principles for layers
• Security constraints should be defined at
the highest layer, where their semantics
are clear, and propagated to the lower
levels, which enforce them.
• All the layers of the architecture must be
secure.
• We can define patterns at all levels. This
allows a designer to make sure that all
levels are secured, and also makes easier
propagating down the high-level
constraints.
Secure Systems Research Group - FAU
We can use patterns at all levels
• Patterns for models define the highest
level
• At each lower level we refine the patterns
at the previous level to consider the
specific aspects of each level
• We’ll analyze some patterns from each
layer
Secure Systems Research Group - FAU
Security layers
Application
Database
Distribution
Operating
System
Hardware
Secure Systems Research Group - FAU
Network
Abstract security patterns (ASPs)
• Describe a conceptual security mechanism that realizes
one or more security policies able to handle (stop or
mitigate) a threat or comply with a security-related
regulation or institutional policy.
• Some of the ASPs correspond to basic security
mechanisms, e.g., Access control (Authorization and
Reference Monitor), Security Logger/Auditor, and
Authenticator.
• Others specify more detailed aspects, e.g. Access
Control/Authorization models include the Access Matrix,
Role-Based Access Control (RBAC), and Multilevel models .
• Starting from ASPs, when building the lifecycle of a
complete application we can use a hierarchy of patterns
going from abstract security patterns to platform-oriented
versions of these patterns and their code realizations.
Secure Systems Research Group - FAU
Authenticator
• How to verify that a subject is who it says
it is? 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.
Secure Systems Research Group - FAU
Class diagram of Authenticator
ASP
Subject
requestAuthent
1
*
id
Authenticator
1
1
verify
1
*
Proof_of_
Identity
Secure Systems Research Group - FAU
*
<<create>>
Authentication
Information
Authentication
<<actor>>
:User
:Authentication
Information
:Authenticator
request
verify
:Proof of
identity
CreateProof_Id
Handle
Figure 3 Authentication Dynamics
Secure Systems Research Group - FAU
Authenticator hierarchy
Authenticator
Distributed
Authenticator
Centralized
Authenticator
Credential
Password
X.509
SAML
Secure Systems Research Group - FAU
Token
Biometric
Card-based
Authorization models
• Used in conceptual models of an
application
• Propagated to the lower levels
Secure Systems Research Group - FAU
Access control
• Authorization: rules that specify who has
access to what and how
• Different models define rules appropriate
for specific environments
• Enforcement: intercept access requests
and verify that they are authorized
• Enforcement is embodied in a Reference
Monitor
Secure Systems Research Group - FAU
XACML
Evaluator
XACML
Policy
MAC
Policy-based
Access Control
Policy
ACL
DAC
Ref.Monitor
Cap
Access
Matrix
Predicate
Access matrix
Copy Flag
Access matrix
Predicate +
copy flag
access matrix
Secure Systems Research Group - FAU
RBAC
ABAC
Session
NIST
Applic. Layer: Access control models
• Authorization. How do we describe who is
authorized to access specific resources in a
system? A list of authorization rules describes
who has access to what and how.
• Role-Based Access Control (RBAC). How do
we assign rights to people based on their
functions or tasks? Assign people to roles
and give rights to these roles so they can
perform their tasks.
• Multilevel Security. How to decide access in an
environment with security classifications.
Secure Systems Research Group - FAU
More access control
• Metadata-Based Access Control, later
renamed Attribute-Based Access Control
(ABAC). Allow access to resources
based on the attributes of the subjects
and the properties of the objects
• Reference Monitor. Enforces the rules
defined by any of these models
Secure Systems Research Group - FAU
Access matrix authorization rules
• Basic rule ( s, o, t ) , where s is a subject
(active entity), t is an access type, and o is
an object
• Extended rule ( s, o , t , p, f) , where p is a
predicate (access condition or guard) and
f is a copy flag
• This, and the other models, can be
described by patterns
Secure Systems Research Group - FAU
Authorization/Access Matrix
Subject
*
isAuthorizedFor
id
name
ProtectionObject
id
name
Right
accessType
checkRights
Secure Systems Research Group - FAU
*
Access Matrix
Subject
*
Authorization_rule
id
*
ProtectionObject
id
Right
access_type
predicate
copy_flag
checkRights
Secure Systems Research Group - FAU
Authorization mapping
protection
objects
subjects
F1
U1
.
Ui
r/w
f=T
Fi
r
f=F
mi
Uj
r/w
f=T
Secure Systems Research Group - FAU
.
Reference Monitor
• Each request for resources must be
intercepted and evaluated for authorized
access
• Abstract concept, implemented as
memory access manager, file permission
checks, CORBA adapters, etc.
Secure Systems Research Group - FAU
Reference Monitor idea
Ui
pi
read F1
F1
Reference
Monitor
Authorization
Rules
Secure Systems Research Group - FAU
if ∃ (Ui, read, F1)
then read F1;
else securityViolation
Reference monitor pattern
Subject
makesRequestTo
*
*
Reference
Monitor
exists
*
Set_of_
Authorization_
*
Rules
Request
prot_Object
access_type
Secure Systems Research Group - FAU
*
Concrete
Reference
Monitor
Authorization
Enforcing access control
:CurrentProcess
<<actor>>
:RefMonitor
request
(acc_type
prot_object)
:Set_of_AuthorizationRules
exists?(rule)
exists
exists
request
Secure Systems Research Group - FAU
:Authorization
:Prot_Object
Role-Based Access Control
• Users are assigned roles according to
their functions and given the needed
rights (access types for specific objects)
• When users are assigned by
administrators, this is a mandatory model
• Can implement least privilege and
separation of duty policies
Secure Systems Research Group - FAU
Basic RBAC pattern
User
*
MemberOf
*
Role
*
Authorization_rule
*
ProtectionObject
id
id
id
name
name
name
Right
access_type
predicate
copy_flag
checkRights
Secure Systems Research Group - FAU
Growing models
• We can grow models by adding classes,
e.g. from Authorization to RBAC we add a
Role class.
• We can add sessions as execution context
• We can add hierarchies of roles and of
objects (Composite pattern)
• Subroles inherit role rights from
superclass roles.
• Access to an object gives implicit access
to its subobjects
Secure Systems Research Group - FAU
Extended RBAC
•
•
•
•
Concept of session
Separation of administrative roles
Composite roles
Groups of users
Secure Systems Research Group - FAU
Role
User
ProtectionObject
roleID
addUser
removeUser
{Subset}
*
* MemberOf
objectID
addRole
removeRole
addUserToRole
removeUserFromRole
*
AuthorizationRule
*
*
userID
addObject
removeObject
*
Right
1
accessType
checkRights
CompositeRole
SimpleRole
WorksOn
CompositeObject
*
Session
*
createSession
endSession
Secure Systems Research Group - FAU
SimpleObject
Extended RBAC pattern
MemberOf
Group
*
User
*
MemberOf
*
*
*
Role
*
1
AuthorizationRule
*
*
*
Right
Composite
Simple
Role
Role
Activated
From
Subset
*
WorksOn
*
Secure Systems Research Group - FAU
Session
AdminRole
AdminRight
ProtectionObject
Attribute-Based Access Control
• In the Internet we need to deal with nonregistered users
• Determine effective subjects and objects
based on attribute values
Secure Systems Research Group - FAU
Mandatory models
• In a mandatory model users are assigned
to classifications by administrators
• Need trusted processes to perform
administrative functions
• Typically use data labels (tags) to enforce
security
• It is the most secure model but it is rigid
3/25/2016
Secure Systems Research Group - FAU
97
Multilevel model
• In this model users and data are assigned
classifications or clearances
• Classifications include levels (top secret,
secret,…), and compartments (engDept,
marketingDept,…)
• For confidentiality, access of users to data is
based on rules defined by the Bell-LaPadula
model, while for integrity, the rules are defined by
Biba’s model
3/25/2016
Secure Systems Research Group - FAU
98
Multilevel security model
AssignLevel
AssignLevel
TrustedProcess
*
*
*
*
*
Subject
1
*
Category
Clearance
Level
3/25/2016
Secure Systems Research Group - FAU
CanAccess
SS_property
*_property
*
*
Category
Data
1
Classification
Level
99
Multilevel properties
• Simple security (ss) property. A subject s
may read object o only if its classification
dominates the object’s classification, i.e.,
C(s) => C(o). This is the no read-up
property.
• *-Property. A subject s that can read
object o is allowed to write object p only if
the classification of p dominates the
classification of o, i.e., C(p) => C(o). This
is the no write-down property.
Secure Systems Research Group - FAU
Basic
Authorization
condition
Content-based
Authorization
s =Role
CopyFlag
s or o =attribute values
Delegatable
Authorization
Basic
RBAC
authorizer
ABAC
session
Session-based
RBAC
Explicitly
Granted
Authorization
session
Secure Systems Research Group - FAU
session
Access Session
session
Session-based
ABAC
Conceptual models in applications
• We can apply the abstract models to
define application constraints and policies
• Example of medical policies
Secure Systems Research Group - FAU
Some policies for medical
information
• Patients can see their records, consent to
their use, must be informed of their use
• A doctor or other medical employee is
responsible for use of record (custodian)
• Records of patients with genetic or
infectious diseases must be related
Secure Systems Research Group - FAU
MedicalRelation
<<role>>
Doctor
1
Custodian
InChargeOf
*
*
MedicalRecord *
1..* read
modify
1
<<role>>
Patient
Right
read
authorizeUse
informPatient
for own Record
Secure Systems Research Group - FAU
Analogy: Sarbanes Oxley policies
for own Investor
FinancialInstitution
Right
read
invest
<<role>>
Broker
Relation
InChargeOf
1
Custodian
1
name
address
ID number
captureInfo
*
exchangeInfo
*
FinancialRecord
*
*
1..*
1
1..*
<<role>>
read
Investor
invest
Right
read
authorizeUse
contact Investor
for own Record
*
FinancialAccount
account number
Secure Systems Research Group - FAU
Investor
name
address
ID number
notify Investor
OCL (Object Constraint Language)
• Similar to Z and SQL, 1st order predicate
calculus
• Adds precision to UML constraints
• Implementation oriented
• Important for safety-critical applications
Secure Systems Research Group - FAU
Operating system layer
• OS architectures
• OS security features
• Virtualization
Secure Systems Research Group - FAU
Operating systems functions
•
•
•
•
Controls system resources
In direct contact with hardware
Process and processor management
Memory management --executing
programs
• Data management: persistent data
• I/O devices -- disks, communications ,…
• Controls login
3/25/2016
Secure Systems Research Group - FAU
108
Processes
•
•
•
•
•
•
•
A process is defined by its Process Control Block (PCB), a data
structure containing its id, and references to its context.
A process should receive a separate address space for its
execution.
A thread is a lightweight process (faster context switching than a
process) and shares its address space with other threads. A
thread includes a program counter, a register set, and a stack.
Because of its shared address space, an error or attack from
another thread can corrupt its memory. Thread stacks can be
protected if they are kept in the system address space using
separated segments or pages.
Most modern operating systems allow several threads to be
bundled in one process; this protects the thread group as a whole
from other processes.
User processes and threads can be created with special
packages, e.g., Posix in Unix, or through the language.
The operating system defines kernel threads as units of
concurrent execution. For the reasons discussed above, kernel
threads usually don’t have much protection against each other.
Secure Systems Research Group - FAU
Process interaction
ordersProcess
kernel
system
calls
messages
po(par)
shippingProcess
Fulfilled Orders
kernel mode
user mode
Pending Orders
Bills
Customer List
Secure Systems Research Group - FAU
Customers
Process communication
• Process communication also has an effect on
security. Systems that use explicit message
passing have the possibility of checking each
message to see if it complies with system
policies.
• A security feature that can be applied when
calling another process is protected entry points.
A process calling another process can only enter
this process at pre-designed entry points. This
prevents bypassing entry checks
• The number and size of arguments in a gate
crossing can also be controlled (this may protect
against some types of buffer overflow attacks)
Secure Systems Research Group - FAU
Execution states or modes
• At least two modes of operation are
needed to have any security.
• Most hardware architectures use a
supervisor and a user mode. In the user
mode some instructions, called privileged
instructions, cannot be executed directly.
In supervisor mode all the instructions
can be executed.
• The state of a process is kept in a
Program Status Word.
3/25/2016
Secure Systems Research Group - FAU
112
3/25/2016
Secure Systems Research Group - FAU
113
Protection rings
• Some architectures define in their hardware a set
of rings (4 to 32) that correspond to domains of
execution with hierarchical levels of trust. Rings
are a generalization of the concept of mode of
operation.
• Crossing of rings is done through gates that
check the rights of the crossing process. A
process calling a segment in a higher ring must
go through a gate.
3/25/2016
Secure Systems Research Group - FAU
114
0 = kernel
1 = OS functions
2 = safe applications
3 = untrusted applications
3
2
1
0
- Calls upward
(higher privilege)
- Data access toward
less privilege
- Gate crossings
- Protected entry points
3/25/2016
Secure Systems Research Group - FAU
115
Protected Entry Point pattern
Calling
Process
Called Process
calls
*
*
id
executeService
id
*
Parameter
name
type
size
Secure Systems Research Group - FAU
Entry Point
*
name
numOfParms
Patterns for OSs
Virtual Address Space
Structure Selection
uses
executes in
Secure Process
Controlled
Virtual Address Space
defines access
Administrator
Hierarchy
faster context switch
authorized by
Secure Thread
created by
RBAC
Controlled Process
Creator
Reference
Monitor
Secure Systems Research Group - FAU
(Role Based Access Control)
define rights
specializes
Authorization
enforced by
Android architecture
Extended Application
…
…
Applications
Reference Monitor
Component
Framework
JVM
Policy Set
Linux OS
Secure Systems Research Group - FAU
Middleware
Symbian
•
•
•
•
•
•
Symbian Os is a hard RTOS
Symbian OS is an open system and is based on a micro kernel
architecture which implements full multitasking and multithreading
The micro kernel uses client/server session based IPC in which servers
mediate access to shared resources and services, and the kernel deals
with memory allocations and IPCs
System services such as telephony, networking middleware and
application engines all run in their own processes
Symbian OS v9.1 provides a proactive defense mechanism against
malware. The platform security infrastructure uses a capability-based
model, which ensures that sensitive operations (for example modifying
user data, making calls, using network connections) can only be accessed
by applications, which have been certified by an appropriate signing
authority
Data caging is a new feature provided by the Symbian OS v9, which allows
applications to have their own private data partition. This allows for
applications to guarantee a secure data store. This can be used for ecommerce, location applications and others.
Secure Systems Research Group - FAU
Symbian layered microkernel
Secure Systems Research Group - FAU
Patterns for secure process management
Secure
Process
lightweight
execution
creation
Controlled
Process Creator
create
Objects
Secure
Thread
Controlled
Object Factory
enforce
Rights
define
Rights
Controlled
Object Monitor
check
Rights
Authorizer
Secure Systems Research Group - FAU
Reference
Monitor
define
Rights
Secure Process/Thread
• How do we make sure that a process does not
interfere with other processes or misuse shared
resources?
• A process is a program in execution, a secure
process is also a unit of execution isolation as
well as a holder of rights to access resources.
• A secure process has a separate virtual address
space and a set of rights to access resources.
• A thread is a lightweight process. A variant,
called secure thread is a thread with controlled
access to resources.
Secure Systems Research Group - FAU
Secure process
Authorization
pattern
enforces
Resource
Subject
id
ReferenceMonitor
pattern
*
ProcessDescriptor
id
program_counter (pc)
data
open_files
registers
stack
child_processes
pending_events
accounting_info
security_info
state
ProcessRight
checkAccess
*
1
VirtualAddressSpace
boundaries
create
delete
save
resume
AssignRight
removeRight
Secure Systems Research Group - FAU
shares
*
1
*
executes
from
1
ProgramCode
Controlled
Virtual
Address
Space pattern
Controlled address space
• Also called Execution domain or sandbox
• Access is controlled through descriptors or capabilities
• As a process executes it creates one or more Domains.
Domains can be recursively composed
• The descriptors used in the process’ domains are a subset
of the Authorizations that the Subject has for some
Protection Objects (defined by an instance of the
Authorization pattern of Chapter 3).
• ProtectionObject is a superclass of the abstract Resource
class and ConcreteResource defines a specific resource.
• Process requests go through a ReferenceMonitor that can
check the domain descriptors for compliance.
• Used in Java, in Haiku, and others
Secure Systems Research Group - FAU
The Controlled Execution Environment
pattern
• Intent: To control access to all operating system
resources by processes, based on user, group, or
role authorizations.
• Context: A process executes on behalf of a user or
role (a subject). A process must have access rights to
use these resources during execution. The set of
access rights given to a process define its execution
domain. Processes must be able to share resources
in a controlled way. The rights of the process are
derived from the rights of its invoker.
Secure Systems Research Group - FAU
Process/domain rights
Process
1
*
Domain
Executes In
*
ID
*
Composite
Domain
ID
create( )
* )
close(
delete( )
Simple
Domain
Activates
Authorization
right
ProtectionObject
*
1
Subject
*
*
ID
create ( )
close( )
delete( )
ID
Resource {A}
name
address
amount
ConcreteResource
3/25/2016
Secure Systems Research Group - FAU
126
Secure Systems Research Group - FAU
Secure Boot
Secure Systems Research Group - FAU
Firefox OS
Secure Systems Research Group - FAU
Patterns in Firefox OS
•
•
•
•
•
•
•
•
Layers
Controlled VAS (sandbox)
Digital Signature
Controlled Process Creator
Multilevel Access Control
Authorizer (ACL)
Whitelisting
Credential
Secure Systems Research Group - FAU
Tizen OS
Secure Systems Research Group - FAU
Patterns in Tizen OS
•
•
•
•
Layers
Controlled VAS (Sandbox)
Multilevel Access Control (Mandatory)
Digital Signature
Secure Systems Research Group - FAU
Forces of VM OS
• Each operating system needs to have access to a
complete set of hardware features to support its
execution.
• Each OS has its own set of machine dependent
features, e.g., interrupt handlers. In other words,
each operating system uses the hardware in different
ways.
• When an OS crashes or it is penetrated by a hacker,
the effects of this situation should not propagate to
other OSs in the same hardware.
• There should be no way for a malicious user in a VM
to get access to the data or functions of another VM.
Secure Systems Research Group - FAU
VM execution
UNIX
Linux
VM1
VM2
VMM (virtual machine monitor)
hardware
Secure Systems Research Group - FAU
VM operating system
VMOS
1
*
<<controls>>
VirtualMachineMonitor
VM
*
*
Can run
*
Supports
*
LocalOS
1
Hardware
*
LocalProcess
Secure Systems Research Group - FAU
UC: Execute a system call
<<actor>>
:LocalProcess
:VirtualMachineMonitor
:LocalOS
:Hardware
OS call
OS call
interpretCall
performOperation
return(…)
return(…)
Secure Systems Research Group - FAU
Known uses
• IBM VM/370 [Cre81]. This was the first VMOS, it
provided VMs for an IBM370 mainframe.
• VMware [Nie00]. This is a current system that
provides VMs for Intel x86 hardware.
• Solaris10 [Sun04] calls the VMs “containers” and one
or more applications execute in each container.
• Connectix [Con] produces virtual PCs to run
Windows and other operating systems.
• Xen is a VMM for the Intel x86 developed as a project
at the University of Cambridge, UK [Bar00]. Used by
VMWare and others
Secure Systems Research Group - FAU
Advantages
• The VMM intercepts and checks all system calls. The
VMM is in effect a Reference Monitor and provides
total mediation on the use of the hardware. This can
provide a strong and secure isolation between virtual
machines.
• Each environment (VM) does not know about the
other VM(s), this helps prevent cross-VM attacks
• There is a well-defined interface between the VMM
and the virtual machines.
• The VMM is small and simple and can be checked for
security and correctness.
Secure Systems Research Group - FAU
Liabilities
• All the VMs are treated equally. If one needs
different categories of VMs it is necessary to
build specialized versions
• Extra overhead in use of privileged
instructions.
• It is rather complex to let VMs communicate
with each other (if this is needed).
• Security attacks are possible (to be seen)
because of implementation additions
Secure Systems Research Group - FAU
Microkernels
Secure Systems Research Group - FAU
The Microkernel pattern (www.vico.org)
•
•
•
"The Microkernel architectural pattern applies to software systems
that must be able to adapt to changing system requirements. It
separates a minimal functional core from extended functionality
and customer-specific parts. The microkernel also serves as a
socket for plugging in these extensions and coordinating their
collaboration." (Buschmann, F., R. Meunier, H. Rohnert, P.
Sommerlad, and M. Stal. Pattern-Oriented Software Architecture:
A System Of Patterns. West Sussex, England: John Wiley & Sons
Ltd., 1996)
The microkernel includes functionality that enables other
components running in separate processes to communicate with
each other. It is also responsible for maintaining system-wide
resources such as files or processes. In addition, it provides
interfaces that enable other components to access its
functionality.
It uses an Adapter pattern to let clients interface with its functions
Secure Systems Research Group - FAU
Microkernel
3/25/2016
Secure Systems Research Group - FAU
142
Reducing kernel mode execution
• If only a few critical functions run in kernel
mode security and reliability improve
• Hypervisors and microvisors run in kernel
mode but all other programs run in user
mode
• Applies principle of Least privilege and
also improves performance
• Can act as a Reference Monitor
Secure Systems Research Group - FAU
Secure Systems Research Group - FAU
The network layers
• Firewalls
• Intrusion Detection Systems
• Network layer defenses
Secure Systems Research Group - FAU
Internet layers
• Layer 7 (HTTP),
• Layer 4 (TCP, Transmission Control
Protocol),
• Layer 3 (IP, Internet Protocol),
• Layer 1.
• At the higher levels, the sub-protocols
used are TCP (a connection-oriented
protocol), and UDP (User Datagram
Protocol)
Secure Systems Research Group - FAU
Secure channels
A p p lica tio n
L a y er
P E M , S -M IM E
M a il S e r vic e
S -H T T P
A p p lication P rotec tion
T ra n sp o rt
L a y er
IP C pr ot e ct io n
P roc ess A
SSL
PCT
P r ocess B
IP
L ayer
N ode 1
N ode 2
P ac ke t pr ote ction
IP S E C
Secure Systems Research Group - FAU
Patterns for firewalls
• Packet Filter Firewall. Filter incoming and
outgoing network traffic in a computer system
based on network addresses.
• Application/Proxy Firewall . Inspect (and filter)
incoming and outgoing network traffic based
on the type of application they are accessing.
• Stateful firewall Filter incoming and outgoing
network traffic in a computer system based on
network addresses and the state information
derived from past communications.
Secure Systems Research Group - FAU
Firewall patterns
Address Filtering
Proxy-Based Firewall
Keep State
Proxy Filtering
Packet Filter Firewall
Address Filtering
Stateful Firewall
Keep State
3/25/2016
Secure Systems Research Group - FAU
149
Application layer (proxy) firewall
• Uses security proxies to represent
services
• A variety of the Proxy pattern
• Prevents direct access
• Analyzes application commands
• Keeps logs for later auditing
Secure Systems Research Group - FAU
Application layer firewall
Firewall
Internal
Server
Request
P
Request
P2
P1
Internet
Private
Network
Secure Systems Research Group - FAU
External
Server
Proxy-based firewall
ExternalHost
address
requestService Proxy-Based
Firewall
*
1
*
Proxy
*
RuleBase
Secure Systems Research Group - FAU
LocalHost
filters
*
represents
1
1
address
*
Service
name
port
In summary
• Firewalls are examples of the Reference
Monitor pattern applying a simple Access
Matrix model
• Packet filter and proxy firewalls
complement each other
• Can be further complemented with
intrusion detection
Secure Systems Research Group - FAU
Application firewall
• Controls input/output from distributed
applications
• Enforces access control according to
application restrictions, can understand
application semantics
• Can also filter wrong operations, wrong
type or length parameters, wrong sequences
of operations
3/25/2016
Secure Systems Research Group - FAU
154
3/25/2016
Secure Systems Research Group - FAU
155
XML firewall
• Controls input/output of XML
applications
• Well-formed documents (schema as
reference)
• Harmful data (wrong type or length)
• Encryption/decryption
• Signed documents
3/25/2016
Secure Systems Research Group - FAU
156
3/25/2016
Secure Systems Research Group - FAU
157
Knowledge-based IDS pattern
Client
Host
id
credentials
address
service()
*
*
SignatureSet
Signature
id
pattern
addSignature()
removeSignature() 1
updateSignature()
*
1
1
AttackDetector
recover
matchSignature()
Countermeasure
execute()
1
1
IDS
requestService
*
3/25/2016
Secure Systems Research Group - FAU
id
requestService()
detectIntrusion()
issueAlert
sendRequest
*
158
«actor»
:Client
:IDS
:Detector
:SignatureSet
:Application
requestService()
matchSignature()
matchSignature()
match()
signatMatched
intrusionDetected()
issueAlert
3/25/2016
Secure Systems Research Group - FAU
159
TLS (SSL) protocol pattern
Secure Systems Research Group - FAU
UC: Request service
Secure Systems Research Group - FAU
Layer defenses
XML
XML Firewall
XML VPN
__
Application
Application Firewall
Layer 7
Proxy-Based Firewall
SSL VPN
Layer 3
Packet-Filter Firewall
IP VPN
Secure Systems Research Group - FAU
Patterns for web services and
cloud computing
•
•
•
•
•
•
Approaches
Authentication
Distribution
Identity
Web services
Cloud Computing
Secure Systems Research Group - FAU
Authentication patterns
• Remote Authenticator /Authorizer. Provide facilities for
authentication and authorization when accessing
shared resources in a loosely-coupled distributed
system.
• Credential. Provide portable means of recording
authentication and authorization information for use in
distributed systems
Secure Systems Research Group - FAU
Web services security
• Application Firewall [Del04]. The application firewall filters
calls and responses to/from enterprise applications, based
on an institution access control policies.
• XML Firewall [Del04]. Filter XML messages to/from
enterprise applications, based on business access control
policies and the content of the message.
• XACML Authorization [Del05]. Enable an organization to
represent authorization rules in a standard manner.
• XACML Access Control Evaluation [Del05]. This pattern
decides if a request is authorized to access a resource
according to policies defined by the XACML Authorization
pattern. .
• WSPL [Del05]. Enable an organization to represent access
control policies for its web services in a standard manner. It
also enables a web services consumer to express its
requirements in a standard manner.
Secure Systems Research Group - FAU
Use of web services
Web Services Repository
2
1 Publicize
Discover
3 Use
Web Services
Provider
Secure Systems Research Group - FAU
Web Services
Client
Standards for web services security
W S-SecureC onversa tion
WSPL
BP EL4W S
WS-Authorization
W SCI
W S-P olicy
W SDL
W S-Trust
We b Se rvic es
WS1
WS-Federatio n
W S-Priv acy
WS2
H EA D E R
C at alog and
De sc rip tion
U DDI
ebXML s ec
Registry
C omm unic atio ns
...
UD DI security
ebXML
SAM L
SAML
Bu sine ss
W or kf low
X ML
Encr yption
P A Y LOA D
XML Encry ption-
X ACML
XML Sig na ture
SOA P
XML
XM L
XKMS
S OAP
T rans po rts
H TT P
D ocu men t
Stora ge
W S-Security
...
D BM S
SS L
OS
T CP/IP
p ro ces s es
memo ry
file s ystem
W e b se rvic es lay er s
Standar ds
Sup port ing st ru c tu re s
Sec urity S t andar ds/ S pec ific at io ns
Secure Systems Research Group - FAU
Secure Systems Research Group - FAU
XACML
• Special technical committee of
OASIS
• Specification of policies for
information access over the Internet
and their enforcement
• Combines work of IBM Tokyo and
University of Milano, Italy.
• Implemented by Sun in early 2003
Secure Systems Research Group - FAU
XACML Authorization
PolicyComponent
-obligation
Action
PolicySet
Policy
+policyCombiningAlgorithm()
+ruleCombiningAlgorithm()
*
*
Resource
*
1..*
-attributes
1
*
Rule
Target
Subject
-effect={Permit,Deny}
-condition
-attributes
1
1
*
Environment
*
-attributes
PolicyAdministrationPoint
+addRule()
+deleteRule()
+updateRule()
+createPolicy()
+deletePolicy()
+createPolicySet()
+deletePolicySet()
Secure Systems Research Group - FAU
*
Reified Reference Monitor
0…1
Decision
Decision
*
*
Actual
Subject
Request
*
*
Reference
Monitor
*
*
Set_of_
Authorization_
Rules
Request
prot_Object
acess_type
1
corresponds to
Secure Systems Research Group - FAU
*
Concrete
Reference
Monitor
Authorization
RRM
• In the RRM the decision, instead of being
‘yes’ or ‘no’, is a class to which we can
apply operations (reification)
• There is zero or one decision per request
• Information about the context or any other
information can be used to produce the
decision
Secure Systems Research Group - FAU
Access control evaluation
Resource
-attributeValues
*
*
isAuthorizedFor
Subject
-attributeValues
XACMLAccessResponse
-decision={Permit,Deny,Indeterminate,NotApplicable}
-obligations
*
*
requestsAccess
PolicyEnforcementPoint
1
1
XACMLAccessRequest
-subjectAttributes
-resourceAttributes
-action
-environmentAttributes
ContextHandler
*
*
1
1
1
PolicyDecisionPoint
ApplicablePolicySet
*
PolicyInformationPoint
+getAttributeValue()
correspondsTo
correspondsTo
correspondsTo
evaluates -policyCombiningAlgorithm
+retrieveApplicablePolicy()
+evaluateApplicablePolicy()
PolicyComponent
*
1
*
PolicyAdministrationPoint
<<creates>>
Secure Systems Research Group - FAU
Abstraction in the use of patterns
• We can see the Composite and
Authorization patterns in XACML
Authorization
• We can see the Reference Monitor in
XACML Evaluation
• Abstraction helps model understanding
Secure Systems Research Group - FAU
Use of encryption in the architecture
Application
user controls
DBMS
storage encryption
OS
cryptographic algorithms
message security
Hardware
Secure Systems Research Group - FAU
Network
hardware support
XML Encryption
• The XML Encryption standard describes
the syntax to represent XML encrypted
data and the process of encryption and
decryption. XML Encryption provides
confidentiality by hiding selected sensitive
information in a message using
cryptography.
Secure Systems Research Group - FAU
Secure Systems Research Group - FAU
Encrypting elements
Secure Systems Research Group - FAU
Secure Shell (SSH)
Intent
• Provide an authenticated environment where users may
utilize programs and securely exchange information with
remote locations. This environment provides
confidentiality via symmetric encryption, authentication via
public key encryption, and non-repudiation via digital
signatures.
Solution
• First, the use of an Internet Key Exchange (IKE) mechanism
[Kau05] is employed in order to set up a shared private key.
In this mechanism, each system first calculates half of a
shared key using an exchange algorithm. The two systems
then exchange their half of the key with the other system.
Finally, each system runs the algorithm on the received
portion of the key. The result for both systems is a
matching value that is then used in a later mechanism.
Secure Systems Research Group - FAU
•
Secure Systems Research Group - FAU
The design of secure
systems
• We not only have to satisfy functional specs
but nonfunctional specs.
• Security is a nonfunctional aspect
• We cannot show absence of security flaws
• We must use good development methods
and hope for the best
• Add-on security is not very secure
3/25/2016
Secure Systems Research Group - FAU
181
Use patterns at all levels
• Patterns for models define the highest
level
• At each lower level we refine the model
patterns to consider the specific aspects
of each level
• Patterns for file systems, web documents,
cryptography, distributed objects, J2EE
components
3/25/2016
Secure Systems Research Group - FAU
182
How to apply the patterns?
• A good catalog and classifications of
patterns help a designer select among
alternatives.
• However, there is still the problem of when
to apply a pattern during system
development
• We need some systematic approach to
decide when we need to use a pattern, a
secure systems methodology
Secure Systems Research Group - FAU
Security principles for application
design
• Security constraints must be defined at the
highest layer, where their semantics are clear,
and propagated to the lower levels, which enforce
them.
• All the layers of the architecture must be secure.
• We can define patterns at all levels. This allows a
designer to make sure that all levels are secured,
and also makes easier propagating down the
high-level constraints.
• We must apply security at all development stages
(tactic-based approaches start from design)
Secure Systems Research Group - FAU
A methodology for building secure
architectures
• Stages
• Financial institution example
Secure Systems Research Group - FAU
Security along the life cycle
Security verification and testing
Requirements
Secure UCs
Analysis
Design
Implementation
Authorization rules in
Rule enforcement Language enforcement
conceptual model
through architecture
Security test cases
Secure Systems Research Group - FAU
A methodology for secure
systems design I
• Domain analysis stage: A business model is defined.
Legacy systems are identified and their security
implications analyzed. Domain and regulatory
constraints are identified. Policies must be defined up
front, in this phase.
• 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. We study
each action within a use case and see which threats
are possible. We then determine which policies would
stop these attacks. From the use cases we can also
determine the needed rights for each actor and thus
apply a need-to-know policy.
Secure Systems Research Group - FAU
Requirements stage
• Use cases are determined
• Activity diagrams for use cases or
sequences of use cases
• Define level of security needed
• Identify attacks
• Select attacks based on risk analysis
Secure Systems Research Group - FAU
Identifying attacks
• We need to know what kind of attacks to
expect.
• We relate attacks to attacker goals
• We study systematically all the possible
attacks to each activity in a use case
• Use cases define all functional
interactions
Secure Systems Research Group - FAU
Attacker goals
• Attacker is not interested in changing a
few bits or destroying a message
• Attacker wants to accomplish some
objective, e.g., steal money, steal identity
• This is applying the principle of defining
security at the semantic levels
• We also need to comply with standards
Secure Systems Research Group - FAU
Example: Applying security
policies to stop threats
• Consider a financial company that provides
investment services to its customers. Customers
can open and close accounts in person or
through the Internet. Customers who hold
accounts can send orders to the company for
buying or selling commodities (stocks, bonds,
real estate, art, etc.). Each customer account is in
the charge of a custodian (a broker), who carries
out the orders of the customers. Customers send
orders to their brokers by email or by phone. A
government auditor visits periodically to check
for application of laws and regulations.
Secure Systems Research Group - FAU
A financial institution
UC1
Open Account
UC2
Close Account
Manager
Customer
UC3
Receive
Trade Order
UC4
Perform trade
Auditor
Broker
UC5
Check Trade Info
3/25/2016
Secure Systems Research Group - FAU
192
From threats to policies
• A systematic way to identify system
threats, and determining policies to stop
and/or mitigate their effects
• Analysis of the flow of events in a use
case or a group of use cases, in which
each activity is analyzed to uncover
related threats. This analysis should be
performed for all the system uses cases
• Then we select appropriate security
policies which can stop and/or mitigate
the identified threats.
Secure Systems Research Group - FAU
3/25/2016
Secure Systems Research Group - FAU
194
External
Attacker
Customer
Manager
Imposter
False
info
Imposter
Provide
Personal
Info
:Customer
Check
Credit
Account1:
Create
Account
Disseminate
Info
Illegally
Create
Spurious
Account
Account2:
Initial
Depo sit
Transfer
Money
Create
Authorization
Account3:
Card1:
3/25/2016
Secure Systems Research Group - FAU
Issue
Card
Issue
Spurious
Card
Card2:
195
Threats
• T1.The customer is an impostor and opens an account in the name
of another person
• T2.The customer provides false information and opens an spurious
account
• T3.The manager is an impostor and collects data illegally
• T4.The manager collects customer information to use illegally
• T5.The manager creates a spurious account with the customer’s
information
• T6.The manager creates a spurious authorization card to access the
account
• T7.An attacker tries to prevent the customers to access their accounts
• T8.An attacker tries to move money from an account to her own
account
3/25/2016
Secure Systems Research Group - FAU
196
Misuses for this use case
• Use Cases 1 and 2: Customer is an impostor. Possible
confidentiality and integrity violations.
Manager impersonation. Can capture customer information.
Confidentiality attack.
• Use Cases 3 and 4. Broker impersonation. Possible
confidentiality violation.
Customer can deny giving a trade order. Repudiation.
Customer impersonation. Confidentiality or integrity
attacks.
Stockbroker embezzling customer’s money.
• Use Case 5. Impersonation of auditor. Confidentiality
violation.
3/25/2016
Secure Systems Research Group - FAU
197
Use case analysis leads to policies
• T1. T3. Mutual authentication. Every interaction across system
nodes is authenticated.
• T2. Verify source of information.
• T4. Logging. Since the manager is using his legitimate rights we can
only log his actions for auditing at a later time.
• T5. T6. Separation of administration from use of data. For example,
a manager can create accounts but should have no rights to
withdraw or deposit in the account.
• T7. Protection against denial of service. We need some redundancy
in the system to increase its availability.
• T8. Authorization. If the user is not explicitly authorized he should
not be able to move money from any account.
Policies can be realized with patterns
3/25/2016
Secure Systems Research Group - FAU
198
Systematic mapping of threats to
policies
Secure Systems Research Group - FAU
Threat enumeration
Misuse Activities
#
T1
T2
T3
T4
T5
T6
T7
T8
T9
T10
T11
T12
T13
T14
T15
T16
T17
T18
T19
T20
Sec. Att.
CO/IN/AV/AC
AC
AV
CO
CO
IN
IN
AC
CO
CO
CO
IN
AC
CO
CO
IN
AV
IN
AC
AV
CO
Source
AIn/UIn/Out
AIn
Out
Out/UIn
Out
AIn
AIn
AIn
AIn
Out/UIn
Out
AIn
AIn
AIn
Out/UIn
AIn
AIn
AIn
Ain
Out
Out/UIn
Secure Systems Research Group - FAU
Description
Disavows having opened this account
Overwhelms application
Eavesdropping
Uncovers cust. relationship with institution by trying to create new account with his info
Provides invalid info (financial, address)
Provides another person's info (name, address, SSN)
Disavows having modified customer credit info
Collects customer personal info to disseminate illegally
Eavesdropping
Collects data illegally as an impostor
Changes the customer credit info to get more clients
Disavows having creating spurious account
Collects customer account info to disseminate illegally
Eavesdropping
Creates spurious account
Does not issue card
Creates a spurious authorization / card
Disavows having authorized money transfer
Overwhelms application
Eavesdropping
Asset
Account
N/A
Customer
Customer
Customer
Customer
Customer
Customer
Customer
Customer
Customer
Account
Account
Account
Account
Card
Card
Account
N/A
Customer
Analysis stage
• Analysis patterns can be used to build the
conceptual model. Security patterns describe
security models or mechanisms. We can build
a conceptual model where repeated
applications of a security model pattern realize
the rights determined from use cases.
Secure Systems Research Group - FAU
Use case analysis leads to policies
•
•
•
•
•
•
T1. T3. Mutual authentication. Every interaction across system
nodes is authenticated.
T2. Verify source of information.
T4. Logging. Since the manager is using his legitimate rights we
can only log his actions for auditing at a later time.
T5. T6. Separation of administration from use of data. For
example, a manager can create accounts but should have no
rights to withdraw or deposit in the account.
T7. Protection against denial of service. We need some
redundancy in the system to increase its availability.
T8. Authorization. If the user is not explicitly authorized he should
not be able to move money from any account.
Policies can be realized with patterns
Secure Systems Research Group - FAU
Use cases can also be used to find
actor rights (authorization rules)
• Use cases describe all possible uses of
the system
• All use cases define all possible and legal
accesses
• Each actor can be given its needed rights
to perform its functions
Secure Systems Research Group - FAU
Scenarios to determine rights
method j
method j+1
.
.
.
method j+m
actor_i
object_k
Authorized actions for actor_i in UseCase_q
Secure Systems Research Group - FAU
object_k + 1
Role rights for financial institution
•
•
•
•
Customers can open/close accounts
Customers can initiate trade
Broker can perform trade
Auditor can inspect (read) trade
transactions
Secure Systems Research Group - FAU
Rights for financial application
Customer
Right
accessType
Account
balance
open
close
trade
id
*
*
* AcctUserRole
*
*
deposit,
withdraw,
trade
creditInfo
Transaction
deposit
withdraw
trade
1
Right
accessType
Secure Systems Research Group - FAU
OwnerRole
open,
close
Adding more security: authentication, logging, separation of duty
openAcct
closeAcct
Not as Acct
User Role
MRight
Account
1
*
*
*
*
log
Authenticator
1
Secure Systems Research Group - FAU
Acct User
Role
*
Transaction
1
…
Manager
*
1
Logger
…
Methodology summary
•
•
•
•
Use case activities define attacks
Attacks lead to policies to stop them
Use cases define needed actor rights
Access matrix or RBAC models formalize
these rights
Secure Systems Research Group - FAU
Security Solution Frames
• Sets of related patterns that partition the
solution space horizontally into separated
but related concerns: Pattern Families,
and vertically according to levels of
abstraction.
• Families treat one part needed to fully
realize a tactic.
• A pattern may belong to more than one
family.
Secure Systems Research Group - FAU
SSF metamodel
Security
Tactic
1
encapsulates
1
1
realizes
relatesTo
1
Security
Solution
Frame
0..*
Solution
Relationship
1
Simple
Security
Pattern
1..*
Security
Pattern
Family
Secure Systems Research Group - FAU
1..*
0..1
Abstract
Security
Pattern
Security
Policy
Canonical abstraction levels
• Conceptual analysis—contains one or more ASPs
to describe the conceptual security solution
• Abstract architecture—contains patterns that
determine a high-level, abstract architecture for
the solution
• Solution design—contains patterns refining the
abstract architecture using more concrete
software components
• Practical implementation details—contains
patterns about specialized aspects of some
technology
Secure Systems Research Group - FAU
Solution relationships
• requires: where solution A requires solution B for its
realization
• supports: where solution B supports solution A in its
realization
• depends on: where the realization of solution A is
dependent in some fashion on the way solution B is
realized.
• derives from: where solution B specializes or derives
certain characteristics from solution A, having a more
specialized context of application.
• alternative: where solution B can be used in place of
solution A
• clashes: where either solution B inhibits the effectiveness
of solution A or solutions A and B are altogether
incompatible and cannot be realized simultaneously.
• Secure Systems Research Group - FAU
Secure Systems Research Group - FAU
Secure Systems Research Group - FAU
Design stage
• When we have the possible attacks to a
system, design mechanisms are selected
to stop these attacks. User interfaces
should correspond to use cases and may
be used to enforce the authorizations
defined in the analysis stage. Secure
interfaces enforce authorizations when
users interact with the system.
Components can be secured by using
authorization rules for components.
Distribution provides another dimension
where security restrictions can be applied.
Secure Systems Research Group - FAU
Design model for financial
application
Account
Authenticate
Branch Office
Authenticate
Central Office
Account
Adapter
Broker
Account
Proxy
AcctUser
Right
Encrypt
Comm.
AcctUser
Right
Secure Systems Research Group - FAU
«View»
Transaction
View
Design stage patterns
• We can map from the application level to
the lower levels
• Next diagram shows the application,
distribution, database/communication,
and operating system/communication
levels
Secure Systems Research Group - FAU
Secure
Layers
Secure
Facade
defineRules
Application
Conceptual
Model
Secure
Reflection
Policy
Administration
Point
Policy
Information
Point
enforceRules
interact
use
Policy
Enforcement
Point
use
decide
Policy
Decision
Point
transformInterface
distribute
objects
Model View
Controller
Secure
Adapter
mapObjects
Secure
Relational
Database
Mapping
consume/provideServices
implement
business
model
Secure
Secure
Secure
Web
Enterprise
Broker
Services
Component
Framework
accessRemote
objects
Secure
Proxy
Secure
establish
Client
Connection Dispatcher
Server
authenticate
support
Software
Secure
Operating
System
Secure Systems Research Group - FAU
secure
Communication
Secure
Channel
Authentication
Security methodology III
• Implementation stage: This stage requires
reflecting in the code the security rules defined in
the design stage. Because these rules are
expressed as classes, associations, and
constraints, they can be implemented as classes
in object-oriented languages. In this stage we can
also select specific security packages or COTS,
e.g., a firewall product, a cryptographic package.
Some of the patterns identified earlier in the cycle
can be replaced by COTS (these can be tested to
see if they include a similar pattern).
Secure Systems Research Group - FAU
Methodology summary
• Use case activities define threats
• Threats must be stopped or mitigated by
applying policies
• Use cases define needed actor rights
• Access matrix or RBAC models formalize
these rights
• We get a secure conceptual model
Secure Systems Research Group - FAU
Design model for financial
application
Account
Authenticate
Branch Office
Authenticate
Central Office
Account
Adapter
Broker
Account
Proxy
AcctUser
Right
Encrypt
Comm.
AcctUser
Right
Secure Systems Research Group - FAU
«View»
Transaction
View
Security is applied along the
distribution path
• Proxies and adapters apply authorization
(Customer access to Accounts)
• Proxies and adapters apply authentication
(Branch office and central office mutual
authentication)
• Logging can be applied in the Transaction
view (not shown)
• Broker communications can be encrypted
• Messages from Customers for trade can
be signed
Secure Systems Research Group - FAU
Implementation stage
• Requires reflecting in the code the security rules
defined in the design stage.
• Because these rules are expressed as classes,
associations, and constraints, they can be
implemented as classes in object-oriented
languages.
• In this stage we can also select specific security
packages or COTS components, e.g., a firewall
product, a cryptographic package
• Some of the patterns identified earlier in the cycle
can be replaced by COTS components (these can
be tested to see if they include a similar pattern).
Secure Systems Research Group - FAU
Functional
Classes
NFR
Classes
Secure Systems Research Group - FAU
J2EE, .NET
Web Services
REST Services
code
Security/Reliability
COTS components
Deployment for financial institution
firewalls
Customers
.
.
.
Internet
message
encryption
ATMs,
Browsers
VPN
authorization
Web
Server
certificates
IDS
Web
Application
Server
certificates
Brokers
Auditors
Secure Systems Research Group - FAU
authorization
encryption
Databases
Reference architectures
• A Domain Model (DM) is a model of an
area of knowledge, e.g. financial systems,
and has no software concepts
• A Reference Architecture (RA) is a generic
architecture, valid for a particular domain,
with no implementation aspects. It is
reusable, extendable, and configurable
• It is a kind of pattern for whole
architectures and it can be instantiated
into a specific software architecture by
adding implementation-oriented aspects.
Secure Systems Research Group - FAU
Cloud Architecture Overview
Cloud Architecture Overview
Secure Systems Research Group - FAU
Class Diagram for Infrastructureas-a-Service architecture
Secure Systems Research Group - FAU
Securing an RA
•
•
•
•
•
•
We start from a list of use cases which describe the typical cloud
uses and their associated roles. Lists of cloud use cases are
shown in [Bad12], [nis11], and [Has13c].
We analyze each use case looking for vulnerabilities and threats
as in [Bra08]. This implies checking each activity in the activity
diagram of the use cases to see how it can be attacked. This
approach results in a systematic enumeration of threats.
We use the list of threats from [Has13a] to confirm these threats
and to find possible further vulnerabilities and threats.
These threats are expressed in the form of misuse patterns. We
developed some misuse patterns for Cloud Computing in
[Has13b], we show more later in the paper.
We apply policies to handle the threats and we identify security
patterns to realize the policies. There are some defenses that
come from best practices and others that handle specific threats.
There are also regulatory policies which are realized as security
patterns.
Secure Systems Research Group - FAU
Vulnerabilities
Threats
Security
Analysis
Countermeasures
Cloud
Misuse patterns
stopped by
Security patterns
Reference Architecture
threats
defenses
IaaS
Paa
S
Saa
S
defenses
Security best practices
Secure Systems Research Group - FAU
Enumerating threats
• We can enumerate threats systematically by
considering each activity in each use case
and analyzing its possible threats
• The approach is systematic and considers all
the activities where attacks can occur. For
illustration we use a running example of a
Virtual Machine Image (VMI) Repository,
which stores VM images for use by service
consumers and which is part of the
administrative functions of the cloud
• We apply to each action in this repository the
STRIDE attacks , e.g. Read a VMI
(confidentiality attack), Tamper a VMI
(integrity attack).
Secure Systems Research Group - FAU
Enumerating threats
Secure Systems Research Group - FAU
Misuse Activities Analysis
Misuse Activity
Actor
Cloud Consumer
Cloud Consumer
Activity
A1:Create
VMI
A2: Send
VMI
#
Sec. Att.
CO/IN/AV/AC
Source
AIn/UIn/Out
IN
Out
CO
Out
IN
Out
AC
Out
CO
AIn/UIn
AV
AIn
IN
UIn/AIn
IN
AIn
T11
T21
T22
T23
IaaS
Administrator
T31
A3:Receive
VMI
T32
T33
IaaS
Administrator
A4: Store
VMI
T41
Secure Systems Research Group - FAU
Attacker
Asset
Malicious
consumer
External
VMI
External
VMI
VMI
Disavows sending a VMI
Collects sensitive
information from VMI
Disavows receiving a
VMI
Insert malicious code in
the image
Malicious
Consumer
Malicious
admin.
Malicious
admin.
Malicious
admin.
VMI
Store poisoned VMI
Malicious
admin. or
consumer
Description
Insert malicious code in
the image
VMI may be read and
copied while being
transmitted
VMI may be modified
while in transit
VMI
VMI
VMI
VMI
: Threat List vs. Defenses
ID
T11
Threats
Defense
The cloud consumer is malicious and inserts malicious Authenticator - Authorizer
code into the VMI
T21
An external attacker listens to the network to obtain Secure Channel
information about the VMI
T22
VMI may be modified while in transit
Secure Channel
T23
Disavows sending a VMI
Security Logger/Auditor
T31
The IaaS administrator is malicious and collects Authenticator - Authorizer
information within the VMI
T32
The IaaS disavows receiving a VMI
Security Logger/Auditor
T33
Insert malicious code in the image
Authenticator - Authorizer
T41
The IaaS administrator stores a malicious VMI
Authorizer – Authorizer
Filter
Secure Systems Research Group - FAU
Cloud security patterns
•
•
•
•
•
•
•
Secure migration process – provides protection for live and offline
migration.
Secure hypervisor – reinforces the security of the hypervisor to avoid
some attacks.
Secure virtual network – secures the communication among virtual
machines.
Virtualized Trusted Platform – provides a framework to determine whether
the environment is secure before launching a virtual machine.
Secure DNS, where Access Control Lists (ACLs) are used to protect the
DNS
Security Group Firewall. A Security Group Firewall divides the firewall in
customer groups that have similar filtering requirements [Fer14b]
Cloud-based Web Application Firewall (CWAF). Controls access to web
applications communicating through HTTP according to authorization
rules with the objective of stopping XSS, SQL injection, and similar
attacks.
Secure Systems Research Group - FAU
Some misuse patterns for clouds
• Covert channels in clouds – covert channels allow
inter-VM communication bypassing the security rules
of the hypervisor.
• Virtual machine escape – describes how to exploit the
hypervisor in order to take control of the underlying
platform.
• Virtual machine hopping – describes how a virtual
machine can access other virtual machines, for
example by exploiting the hypervisor.
• Sniffing virtual networks – describes how a virtual
machine can listen to the virtual network traffic in
order to get confidential information.
• Spoofing virtual networks – describes how a
malicious virtual machine can intercept information in
the virtual network with the purpose of altering its
routing function.
Secure Systems Research Group - FAU
Secure Reference Architecture
• The identified threats can be neutralized
by applying appropriate security patterns.
• Each threat can be controlled by a
corresponding security pattern. Once
security patterns are identified, we apply
them into the reference architecture in
order to stop or mitigate the threats
• Security mechanisms are added to the
basic RA, including Authenticator,
Authorizer, Security Logger/Auditor and
others that mitigate specific threats
Secure Systems Research Group - FAU
Secure Systems Research Group - FAU
Validation of the SRA
• RAs are not directly implementable; they are abstract
models and cannot be evaluated with respect to security
or performance through experimentation or testing.
• An RA is similar to a pattern and it has similar value, it is
a paradigm to guide implementation of new systems or
evaluation of existing systems.
• Their evaluation must be based on how well they
represent the relevant concepts of the systems they
describe, how well they handle abstract threats, how
complete they are, how precise they are, how they can
be applied to the design or evaluation of systems, and
how useful they are for other relevant functions.
• Their final validation comes from practitioners using
them to build concrete architectures.
Secure Systems Research Group - FAU
Uses of a SRA
• Security Service Level Agreement (SSLA). An RA can
provide a framework for defining the requirement of the provider
with respect to the requirements of the consumer; the SRA can
define the security mechanisms that the SP has or could have
and the customer can then select them for the corresponding
SSLA. In particular, a SSLA can include several levels and the
SRA makes clear where the services belong. SSLAs require
monitoring to assure that the SP fulfilled its contact.
• Reference for monitoring functions. Monitoring requires
mechanisms to obtain information about the system status.
A SRA provides guidelines about the places where security
events should be collected in order to fulfill SLAs
requirements and for system administration.
Secure Systems Research Group - FAU
Pattern mining
• How do we find patterns?
• Look at the architecture of systems you
know, can you see similar ideas?
• Look for analogies in systems. If two or
more systems have similar ways of
solving a problem you have a pattern
• Describe standards and regulations, e.g.
HIPAA, Sarbanes-Oxley, FEMA. Web
services security standards
Secure Systems Research Group - FAU
Conclusions
• Security patterns are a useful tool to build secure
architectures
• They require appropriate methodologies to use them,
good catalogs and tools
• They provide a good way to handle security in a
holistic way, necessary for complex systems
• Patterns are also valuable for evaluating existing
systems and for teaching security concepts
• Reference architectures can simplify secure
application development or can be used to build
secure architectures that conform to some type of
application, e.g. clouds
Secure Systems Research Group - FAU
Conclusions II
• Patterns cannot prevent attacks that
happen through code flaws but can make
their effect much less harmful
• Patterns can be made more formal: OCL
• Security patterns are now accepted by
many companies, Microsoft, Sun,
Siemens, and IBM have books, papers,
and web pages on this subject.
• A general page for security patterns:
www.securitypatterns.org
Secure Systems Research Group - FAU
Current/Future work
• More security and misuse patterns
• Improvement of the methodology: add process
aspects, combine with tactics, build tools
• Development of secure and compliant
applications that can fit specific platforms
• Administration and monitoring
• Generating secure and compliant applications out
of domain models and reference architectures
• Cyber-physical systems
Secure Systems Research Group - FAU
Future Work on SRAs
• Some cloud security defenses can be
represented as a form of security patterns
including:
– Secure VM migration process
– Secure hypervisor
– Secure virtual networks
– Secure VNICs
– SDN security patterns
– Cloud data protection
Secure Systems Research Group - FAU
Other variations of patterns
• Privacy patterns—describe privacy policy
definition, negotiation, and enforcement
• Cyber-Physical security patterns--describe security mechanisms for
physical systems: access to buildings,
secure SCADA systems
• Dependability patterns---combine security
and fault tolerance/safety/reliability
Secure Systems Research Group - FAU
Papers
Look in my web page:
http://www.cse.fau.edu/~ed
Research Gate
Write to: [email protected]
Secure Systems Research Group - FAU