Security risks in clouds and grids
This presentation is the property of its rightful owner.
Sponsored Links
1 / 29

Security Risks in Clouds and Grids PowerPoint PPT Presentation


  • 85 Views
  • Uploaded on
  • Presentation posted in: General

Security Risks in Clouds and Grids. Condor Week May 5 , 2011. Elisa Heymann Computer Architecture and Operating Systems Department Universitat Aut ònoma de Barcelona [email protected] Barton P. Miller James A. Kupsch Computer Sciences Department University of Wisconsin

Download Presentation

Security Risks in Clouds and Grids

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Security risks in clouds and grids

Security Risks in Clouds and Grids

Condor Week

May 5, 2011

Elisa Heymann

Computer Architecture andOperating Systems Department

UniversitatAutònoma de Barcelona

[email protected]

Barton P. Miller

James A. Kupsch

Computer Sciences Department

University of Wisconsin

[email protected]

1


Security risks in clouds and grids

1

4

5

2

3

Efficient execution of SPMD Applications on Multicore Environments

Multicore Environment

Objective

Hierarchical

communication

architecture

  • Maximum Speedup

  • Efficiency over a defined

  • threshold

Problem

Edge tile

Idle Time

Internal tile

SPMD Tile

Core

Communications

SuperTile allows to overlap the internal computation with edge communication

How?

Methodology

SPMD Application

Message Passing

Interface

Ideal Size of Supertile

Ideal Number of Core


Security risks in clouds and grids

ParallelApplicationSignaturefor performance prediction

Instrumentation

ParallelApplication

Base Machine

BuildParallelApplicationSignature

(CoordinatedCheckpoint + Phases + Weights)

PatternsIdentification

Collection data

ExtractPhases and Weights

ParallelApplicationModel

Target Machine B

Target Machine A

S

S

Time of eachPhasebyweight

Time of eachPhasebyweight

Prediction

Prediction


Possible threat

Possible Threat?

  • Clouds and Gridshavedatabaseswithmanagement and operationalinformation

  • Denial of Service:

    • Preventupdates in thedatabase

4


Possible threat1

Possible Threat?

  • Hijack machines

    • Process escapes Cloud/Grid/control: Keepsforking and exitingto escape detection.

?

Evil JobPID n

Evil JobPID 3

Evil JobPID 2

Evil JobPID 1

. . .

fork

fork

fork

5


Possible threat2

Possible Threat?

  • Cloud/Grid Accounting System

    • Maintains a Grid-wide view of resource utilization.

      • Job Submission (Priority in the batch queue, CPU time, Memory usage)

      • Storage (Disk usage, Tape storage)

    • Accounting Information easily available to people (web interface) and to applications (Web Services)

  • Use the Accounting System for bad purposes.

6


Possible threat3

7

Possible Threat?


Real threat

8

Real Threat!

Found

and Fixed


What the bad guys can do

9

What the bad guys can do

  • Gain root access

  • Privilege escalation

    • Gain higher privilege access (admin, condor)

  • Hijack machines

    • Attack the process running there


What the bad guys can do1

10

What the bad guys can do

  • Injections

    • Command

    • SQL

    • Directory traversal

    • Log

  • Stringuser= request.getParameter("user");

  • Stringpassword= request.getParameter("password");

  • Stringsql= "select * fromuserwhereusername=' " + user + " ' and password=' " + password+" ' ";

' or '1'='1'--


What the bad guys can do2

11

What the bad guys can do

  • Injections

    • Command

    • SQL

    • Directory traversal

    • Log

  • Denial of Service (DoS)


What the bad guys can do3

12

What the bad guys can do

  • Injections

    • Command

    • SQL

    • Directory traversal

    • Log

  • Denial of Service (DoS)


Why do we care

13

Why do we care

  • Machines belonging to a cloud/grid site are accessible from the Internet

    • Hundred of thousands of machines are appealing

  • Those machines are continuously probed:

    • Attackers trying to brute-force passwords

    • Attackers trying to break Web applications

    • Attackers trying to break into servers and obtain administrator rights


Why do we do it

14

Why do we do it

  • SW has vulnerabilities

  • Cloud and Grid SW is complex and large

  • Vulnerabilities can be exploited by legal users or by others


Why do we do it1

15

Why do we do it

  • Attacker chooses the time, place, method, …

  • Defender needs to protect against all possible attacks (currently known, and those yet to be discovered)


Key issues for security

16

Key Issues for Security

  • Need independent assessment

    • Software engineers have long known that testing groups must be independent of development groups

  • Need an assessment process that is NOT based solely on known vulnerabilities

    • Such approaches will not find new types and variations of attacks


Our piece of the solution space

Our Piece of the Solution Space

First Principles Vulnerability Assessment:

An analyst-centric (manual) assessment process.

You can’t look carefully at every line of code so:

Don’t start with known threats …

… instead, identify high value assets in the code and work outward to derive threats.

  • Start with architectural analysis,

then identify key resources andprivilege levels, component interactionsand trust delegation, then focused component analysis.

17


First principles vulnerability assessment understanding the system

First Principles Vulnerability AssessmentUnderstanding the System

Step 1: Architectural Analysis

  • Functionality and structure of the system, major components (modules, threads, processes), communication channels

  • Interactions among components and with users


Architectural analysis condor

OS privileges

condor & root

user

ArchitecturalAnalysis: Condor

Condor execute host

1. fork

1. fork

5. Negotiator cycle

Condor submit host

Condor execute host

Stork server host

stork_server

negotiator

collector

startd

starter

master

shadow

schedd

submit

master

master

master

job

5. Negotiator cycle

6.Report match

1. fork

1. fork

1. fork

6.Report match

2. machine ClassAd

4. job ClassAd

8. fork

8. fork

7.claim host

3. submit job ClassAd

10. start job

9. establish channel


First principles vulnerability assessment understanding the system1

First Principles Vulnerability AssessmentUnderstanding the System

Step 2: Resource Identification

  • Key resources accessed by each component

  • Operations allowed on those resources

    Step 3: Trust & Privilege Analysis

  • How components are protected and who can access them

  • Privilege level at which each component runs

  • Trust delegation


Security risks in clouds and grids

Resource Analysis: Condor

(b) Unique Condor Checkpoint Server Resources

OS privileges

condor

root

user

(a) Common Resources on All Condor Hosts

Send and Receive Checkpoints

(with Standard Universe Jobs)

generic Condor daemon

ckpt_server

User Job

starter

shadow

(c) Unique Condor Execute Resources

(d) Unique Condor Submit Resources

log

etc

spool

Operational

Log Files

Condor

Config

Condor

Binaries &

Libraries

Operational

Data &

Run-time

Config Files

System Call Forwarding and Remove I/O

(with Standard Universe Jobs)

execute

ckpt

user

Job Execution

Directories

Checkpoint Directory

User’s Files


First principles vulnerability assessment search for vulnerabilities

First Principles Vulnerability AssessmentSearch for Vulnerabilities

Step 4: Component Evaluation

  • Examine critical components in depth

  • Guide search using:

    Diagrams from steps 1-3

    Knowledge of vulnerabilities

  • Helped by Automated scanning tools


First principles vulnerability assessment taking actions

First Principles Vulnerability AssessmentTaking Actions

Step 5: Dissemination of Results

  • Report vulnerabilities

  • Interaction with developers

  • Disclosure of vulnerabilities


Our experience

Our Experience

Condor, University of WisconsinBatch queuing workload management system15 vulnerabilities600 KLOC of C and C++

SRB, SDSCStorage Resource Broker - data grid5 vulnerabilities280 KLOC of C

MyProxy, NCSACredential Management System5 vulnerabilities25 KLOC of C

glExec, NikhefIdentity mapping service5 vulnerabilities48 KLOC of C

Gratia Condor Probe, FNAL and Open Science GridFeeds Condor Usage into Gratia Accounting System3 vulnerabilities1.7 KLOC of Perl and Bash

Condor Quill, University of WisconsinDBMS Storage of Condor Operational and Historical Data6 vulnerabilities7.9 KLOC of C and C++

24


Our experience1

Our Experience

Wireshark, wireshark.orgNetwork Protocol Analyzer in progress 2400 KLOC of C

Condor Privilege Separation, Univ. of WisconsinRestricted Identity Switching Module21 KLOC of C and C++

VOMS Admin, INFNWeb management interface to VOMS data 35 KLOC of Java and PHP

CrossBroker, UniversitatAutònoma de BarcelonaResource Mgr for Parallel & Interactive Applications97 KLOC of C++

25


Our experience2

Our Experience

ARGUS 1.2, HIP, INFN, NIKHEF, SWITCH gLiteAuthorizationServicein progress

glExec 0.8,NikhefIdentity mapping service

26


What do we do

27

What do we do

  • Make cloud/grid software more secure

  • Make in-depth assessments more automated

  • Teach tutorials for users, developers, admin, managers:

    • Security risks

    • Vulnerability assessment

    • Secure programming


Who we are

28

Who we are

  • Elisa Heymann

  • Eduardo Cesar

  • Jairo Serrano

  • Guifré Ruiz

  • Manuel Brugnoli

  • Bart Miller

  • Jim Kupsch

  • Karl Mazurak

  • RohitKoul

  • Daniel Crowell

  • Wenbin Fang


Security risks in clouds and grids1

Security Risks in Clouds and Grids

Elisa Heymann

[email protected]

Barton P. Miller

James A. Kupsch

[email protected]

http://www.cs.wisc.edu/mist/

http://www.cs.wisc.edu/mist/papers/VAshort.pdf

29


  • Login