A SECURITY REFERENCE ARCHITECTURE FOR CLOUD SYSTEMS Eduardo B. - - PowerPoint PPT Presentation

Secure Systems Research Group - FAU

A SECURITY REFERENCE ARCHITECTURE FOR CLOUD SYSTEMS

Eduardo B. Fernandez

• Dept. of Computer Science and Engineering

Florida Atlantic University Boca Raton, FL, USA http://www.cse.fau.edu/~ed ed@cse.fau.edu

Secure Systems Research Group - FAU

Abot me t 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,…
• Ing Elect. UTFSM, MS EE Purdue U, PhD CS

UCLA

• Now a visiting professor in Chile (UTFSM)

Secure Systems Research Group - FAU

Secure Systems Research Group - FAU

Secure Systems Research Group - FAU

Objecti ctivet et

• Get a panorama of security patterns and

their use

• Consider a systematic approach to build

secure systems based on patterns and UML

• Building Security Reference Architectures

for Clouds using patterns

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

Security objectives

• Confidentiality--no leakage of sensitive or

private information

• Integrity-- no unauthorized modification or

destruction of information

• Availability (No denial of service) --

annoying , costly

• Accountability (Non-repudiation)-- legally

significant

Secure Systems Research Group - FAU

Countermeasures

• Identification and Authentication– we must know

who are you

• Access control/ authorization --provide

confidentiality and integrity

• Information hiding (cryptography,

steganography)– making information unintelligible

• Auditing-- basis for prosecution or improvements

to the system

• Intrusion detection—attack alerting

Secure Systems Research Group - FAU

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, emphasis on development speed, no features that can be sold,…

Secure Systems Research Group - FAU

Remedies

• Help designers build secure code using a

systematic approach, even if they do not know much about security

• Provide units of security (packed

solutions to specific problems) with catalogs and tools

• Build security together with the functional

part of the application

• Use a model-based approach

Secure Systems Research Group - FAU 8/9/13 11

Approaches to security

UML/OCL models Security patterns Model checking and composability

• f systems

Vulnerability analysis Code examination Best practices Theoretical Analysis of Security Model-driven Security Code-based Security Certification Certification Verification

Secure Systems Research Group - FAU

8/9/13

12 Need for a conceptual approach I

• Security should be applied where the

application semantics is understood

• Security is an all-levels problem
• We should start from high-level policies

that can be mapped to the lower levels

• We need precise models to guide system

development

• Consider a layered architecture

Secure Systems Research Group - FAU

8/9/13

13 Need for conceptual structure II

• A unified system is easier to understand:

better design, better administration

• Easier to analyze effect of new hardware
• r software
• Start from policies and models
• Apply security throughout the lifecycle

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 slowly 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

Value of security patterns

• Can describe security principles (Single

Point of Access) or security mechanisms (Firewalls)

• Can guide the design and implementation
• f 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

• 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

Structure of the solution

address address PFFirewall ExplicitRule DefaultRule ExternalHost LocalHost Rule in/out {ordered} * 1 1 1 * * requestService requestService RuleBase addRule deleteRule modifyRule reorderRules

Secure Systems Research Group - FAU

Filtering a client’s request

«actor» :ExtHost :Firewall :RuleBase :Rule :LocalHost requestService( ) requestService( ) accept accept checkRule requestService( )

Secure Systems Research Group - FAU

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

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

• 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

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 id name ProtectionObject id name * * Authorization_rule

Right

access_type predicate copy_flag checkRights Role id name * * MemberOf

Secure Systems Research Group - FAU

Session-based RBAC Basic Authorization

authorizer

Session-based ABAC Delegatable Authorization Basic RBAC Content-based Authorization Explicitly Granted Authorization ABAC

s =Role s or o =attribute values

session condition session CopyFlag

Access Session

session session

Secure Systems Research Group - FAU

Web services security

• Application Firewall [Del04]. The application firewall filters

calls and responses to/from enterprise applications, based

• n 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

WS1 WS2 Registry

. . . . . .

Transports HTTP D ocument Storage

Web Services Business Workflow C atalog and Description C omm unicatio ns

D BMS SSL OS TCP/IP

file system memory processes BPEL4WS WSCI UDDI ebXML WSDL SOA P XML X ML

Standards Security Standards/ Specificatio ns

ebXML sec WSPL WS-Security

• XML Encryption

XML Signature XKMS Encr yption SAM L X ACML WS-Policy WS-Authorization UD DI security WS-Trust WS-Federation WS-SecureC onversation

SOAP XML

Web services lay ers Supporting structures

SAML WS-Privacy

Standards for web services security

Secure Systems Research Group - FAU 8/9/13 28

XML firewall

• Controls input/output of XML

applications

• Well-formed documents (schema as

reference)

• Harmful data (wrong type or length)
• Encryption/decryption
• Signed documents

Secure Systems Research Group - FAU 8/9/13 29

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

+policyCombiningAlgorithm() PolicySet +ruleCombiningAlgorithm() Policy

• effect={Permit,Deny}
• condition

Rule 1 Target

• attributes

Resource

• attributes

Subject Action

• attributes

Environment * * * * +addRule() +deleteRule() +updateRule() +createPolicy() +deletePolicy() +createPolicySet() +deletePolicySet() PolicyAdministrationPoint 1 *

• obligation

PolicyComponent 1..* * * 1

Secure Systems Research Group - FAU

Access control evaluation

PolicyAdministrationPoint +retrieveApplicablePolicy() +evaluateApplicablePolicy()

• policyCombiningAlgorithm

PolicyDecisionPoint PolicyEnforcementPoint evaluates PolicyComponent ApplicablePolicySet ContextHandler 1 * correspondsTo +getAttributeValue() PolicyInformationPoint

• attributeValues

Subject

• attributeValues

Resource 1 * 1 1 *

• decision={Permit,Deny,Indeterminate,NotApplicable}
• obligations

XACMLAccessResponse * * 1 1 correspondsTo * * <<creates>> requestsAccess

• subjectAttributes
• resourceAttributes
• action
• environmentAttributes

XACMLAccessRequest * * isAuthorizedFor correspondsTo

Secure Systems Research Group - FAU

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

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 along the life cycle

Security verification and testing Requirements Analysis Design Implementation

Secure UCs Authorization rules in conceptual model Rule enforcement through architecture Language enforcement

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
• bjective, 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

A financial institution

Open Account Close Account Customer Perform trade Receive Trade Order Manager Check Trade Info Auditor Broker

UC1 UC2 UC3 UC4 UC5

Secure Systems Research Group - FAU

Check Credit Provide Personal Info Customer Manager Create Account Create Authorization Initial deposit :Card1 :Customer Account1: Create Authorization

Secure Systems Research Group - FAU

Provide Personal Info Check Credit Create Account Initial Deposit Create Authorization Issue Card Disseminate Info Illegally Issue Spurious Card Transfer Money Account1: :Customer Account2: Account3: Card1: Card2: Create Spurious Account Imposter Imposter False info Customer Manager External Attacker Provide Personal Info Check Credit Create Account Initial Deposit Create Authorization Issue Card Disseminate Info Illegally Issue Spurious Card Transfer Money Account1: :Customer Account2: Account3: Card1: Card2: Create Spurious Account Imposter Imposter False info Customer Manager External Attacker

Secure Systems Research Group - FAU

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

Secure Systems Research Group - FAU

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

Right accessType deposit, withdraw, trade AcctUserRole OwnerRole creditInfo Account balance

• pen

close trade Transaction deposit withdraw trade Right accessType Customer id 1 * * * * *

• pen,

close

Rights for financial application

Secure Systems Research Group - FAU

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 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

Misuse/Attack patterns

• It is not clear to an inexperienced designer what

security pattern should be applied to stop a specific attack

• Security patterns are not useful either for

forensics because they do not emphasize the modus operandi of attacks.

• Attack patterns describe, from the point of view
• f the attacker, how a type of attack is performed

(what system units it uses and how), proposes ways of stopping the attack by enumerating possible security patterns that can be applied for this purpose, and helps analyzing the attack once it has happened by indicating where can we find forensic data as well as what type of data.

Secure Systems Research Group - FAU

Current work

• Cloud Computing definition

– According to NIST, Cloud Computing is “a model for enabling convenient, on-demand network access to a shared of pool configurable computing resources (e.g. networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction”.

Secure Systems Research Group - FAU

Latest results

• Performed a systematic survey of security issues for cloud

environments where we enumerated the main cloud threats, vulnerabilities , and possible defenses found in the literature

• Developed a reference architecture to have a precise view
• f cloud systems to be used as a framework for security
• Described three specific cloud threats in the form of misuse

patterns: – Resource Usage Monitoring Inference – Malicious Virtual Machine Creation – Malicious Virtual Machine Migration.

• Showed how to secure a reference architecture by applying

security patterns to add security defenses and misuse patterns to evaluate its security level. – Developed a pattern for a secure virtual machine repository system

Secure Systems Research Group - FAU

Analysis of Security Issues

• A categorization of security issues for

Cloud Computing focused in its service models SaaS, PaaS and IaaS.

• We identify the main vulnerabilities and

the most important threats.

• We also present some countermeasures

related to these threats.

Secure Systems Research Group - FAU

Vulnerabilities in Cloud Computing

Secure Systems Research Group - FAU

Vulnerabilities in Cloud Computing

Secure Systems Research Group - FAU

Threats in Cloud Computing

Secure Systems Research Group - FAU

Relationships between Threats, Vulnerabilities, and Countermeasures

Secure Systems Research Group - FAU

Reference Architecture

• Our proposed reference architecture

includes: – Use case models

• Common use cases
• Use cases for IaaS
• Use cases for PaaS
• Use cases for SaaS

– Patterns for IaaS, PaaS, and SaaS

Secure Systems Research Group - FAU

Cloud Architecture Overview

Cloud Architecture Overview

Secure Systems Research Group - FAU

Use Cases Common Use Cases for Cloud Computing

Secure Systems Research Group - FAU

UCs: Create VMI and Publish VMI

Secure Systems Research Group - FAU

Misuse Activity Actor Actio n #

• Sec. Att.

CO/IN/AV/ AC Source AIn/UIn/Out

Description Ass et Cloud Consum er Creat e VMI T1 IN Out Insert malicious code in the image VM I Cloud Consum er Send VMI T2 CO Out VMI may be read while being transmitted VM I T3 IN Out VMI may be modified while in transit VM I T4 AC Out Disavows sending a VMI VM I IaaS Administ rator Recei ve VMI T5 CO AIn/UIn Collects sensitive information from VMI VM I T6 AV AIn Disavows receiving a VMI VM I T7 IN UIn/AIn Insert malicious code in the image VM I

Secure Systems Research Group - FAU

ID Threats Defense T 1 The cloud customer is an impostor and publishes a VMI A u t h e n t i c a t o r - Authorization T 2 The cloud consumer inserts malicious code within a VMI Filter module T 3 An external attacker listens to the network to obtain information about the VMI Secure network T 4 The IaaS administrator is an impostor and collects information within the VMI A u t h e n t i c a t o r - Authorization T 5 The IaaS administrator creates a malicious VMI Filter module T 6 T 7

Secure Systems Research Group - FAU

Class Diagram for Infrastructure- as-a-Service architecture

Secure Systems Research Group - FAU

Infrastructure-as-a-Service Pattern

Sequence Diagram for Use Case Create a Virtual Machine

Secure Systems Research Group - FAU

Class Diagram for a Cloud Computing Environment

Secure Systems Research Group - FAU

Malicious VM Creation

• Intent

– An attacker may create a VM image that contains malicious code. – The attacker may read also confidential data from images.

• Context

– Some IaaS providers offer a VM image repository where users can retrieve images in order to initialize their VM.

Secure Systems Research Group - FAU

Secure Reference Architecture

Securing a cloud reference architecture

Secure Systems Research Group - FAU

Conclusions I

• We considered the use of security patterns and

looked in detail at some of them.

• We classified security patterns using

architectural levels and surveyed some patterns previously developed by us and

• thers
• We considered a methodology to apply

security patterns to build secure systems

• Patterns are also valuable for evaluating

existing systems and for teaching security concepts

Secure Systems Research Group - FAU

Conclusions II

• Patterns cannot prevent attacks that

happen through code flaws but can make their effect much less harmful

• Fixing design errors after coding is very

expensive

• Patterns can be made more formal: OCL
• Security patterns are now accepted by

many companies, Microsoft, Sun, 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

Future Work

• Some security defenses can be

represented as a form of security patterns including: – Secure migration process – Secure hypervisor – Secure virtual networks – Virtualized trusted platform module – Cloud data protection – Secure VMI repository

Secure Systems Research Group - FAU

Future Work

• Possible uses of a reference architecture:

– It can be used as a reference for security certification of services. – It can be used to support standards. – It can be used to provide general information before migrating any existing process or system to a cloud. – To define SLAs

Secure Systems Research Group - FAU

Future Work

• Completing the catalog of misuse patterns

– Covert channels in clouds – Virtual machine escape – Virtual machine hopping – Sniffing virtual networks – Spoofing virtual networks

Secure Systems Research Group - FAU

Publicaciones

• Anton Uzunov, E.B.Fernandez, and Katrina Falkner,

"Securing Distributed Systems using Patterns: A Survey", Computers & Security, 2012 http://dx.doi.org/10.1016/j.cose.2012.04.005

• Fernandez, E.B.; Ajaj, O.; Buckley, I.; Delessy-Gassant, N.;

Hashizume, K.; Larrondo-Petrie, M.M. A Survey of Patterns for Web Services Security and Reliability Standards. Future Internet 2012, 4, 430-450. http://www.mdpi.com/ 1999-5903/4/2/430/

• M. VanHilst, E.B.Fernandez, and F. Braz, "A

multidimensional classification for users of security patterns", Journal of Research and Practice in Information Technology, vol. 41, No 2, May 2009, 87-97

Secure Systems Research Group - FAU

Publications

• K. Hashizume, D. G. Rosado, E. Fernandez-Medina, and E. B. Fernandez, “An

Analysis of Security issues for Cloud Computing,” accepted for the Journal of Internet Computing.

• K. Hashizume, E. B. Fernandez, and M. M. Larrondo-Petrie, “Cloud Service Model

Patterns,” in 19th Conference on Pattern Languages of Programs, 2012.

• K. Hashizume, E. B. Fernandez, and M. M. Larrondo-Petrie, “A pattern for Software-

as-a-Service in Clouds,” in Workshop on Redefining and Integrating Security Engineering (RISE’12), Washington, DC, USA, 2012.

• K. Hashizume, E. B. Fernandez, and M. M. Larrondo-Petrie, “Cloud Infrastructure

Pattern,” in First International Symposium on Software Architecture and Patterns, in conjunction with the 10th Latin American and Caribbean Conference for Engineering and Technology, Panama, 2012.

• K. Hashizume, N. Yoshioka, and E. B. Fernandez, “Three Misuse Patterns for Cloud

Computing,” in Security Engineering for Cloud Computing: Approaches and Tools, D.

• G. Rosado, D. Mellado, E. Fernandez-Medina, and M. Piattini, Eds. IGI Global, 2013,
• pp. 36–53.
• K. Hashizume, N. Yoshioka, and E.B.Fernandez, "Misuse Patterns for Cloud

Computing", Procs. of Asian PLoP 2011.

• Keiko Hashizume, Eduardo B. Fernandez, and Nobukazu Yoshioka, "Misuse patterns

for cloud computing: Malicious virtual machine creation"", Procs. of the Twenty-Third International Conference on Software Engineering and Knowledge Engineering (SEKE 2011), Miami Beach, USA, July 7-9, 2011, (Acceptance rate: 31%)