Aspects of application security

Jens Jensen, STFC3rd T&S workshop, NeSC

08-09 July 2008

Contents

•Why•Who needs it•Where do we need it•What is it and what do we need•What do we have already?•How do we do it?

Why Apps Security

• Data is precious, or confidential• Work is confidential• Result is expensive, or confidential• Resources are expensive• Applications (or libraries) are

restricted• Compliance with regulations

Who needs it (stakeholders)

• Data owner, controller• Application owner• Resource owner• Funding body

Where?

• Grid? Clouds? Distributed computing?

• Desktop?• From my perspective:

– All of the above (probably)

Paranoid calculation...

fE(d)=Ef(d)

or fE(d)=E'f(d) Linear E

manageability

ScienceApps

IDs

attrs

fabric

data

results

infra

mware

time

social

usability

availability

users

admins

authorities

Old Chestnuts• Security in depth• Consistency (across data replicas)• Also at application level (how to

unlock the data)– Legacy apps conversion– Unlocking data with legacy apps

• Secure programming• Trust

Applications – APIs

• APIs– Web services– Grid– Cloud– Local– RPC

• Fine grained access control (architecture?)

• Auditing• Protecting data• Trust in result

Access to Apps

• Licensing– License managers

• Commercial vs academic• Payment and subscription models

– Sustainability of service

Trust in Attribute Authorities

• Attributes authorise access to resources• An attribute authority issues attributes for

users• How do you know it can be trusted?• Do you understand what it says?• Is it protected? What are best practices?

Building blocks

• Long term signatures– Maintained against time– Changing identities– Changing crypto (vulnerabilities, apps

support)

• Algorithms

Trust in Service Provider

• Cloud model and grid model– Using remote resources, provided by

ext'l provider

CallingAPI

Uploadingapps

Different security aspects

Accounting

• Account for resource usage– By user, VO– Currently wallclock, CPU

• Available (to user? VO? others?)

Environment

• Sandboxes• Restricting what

students can do• Runaway jobs• Leftovers from

previous jobs

• WLCG:• Jobs running

other jobs (or forking)

• Jobs pulling in apps

• Jobs changing UID

Interoperability

• Standards are important– That's why there are so many to choose

from...

• Interoperation between Grids– Don't throw the baby out with the bathwater

• Interoperability is important– Work within (or hook into) users'

infrastructure

Levels of Assurance

• Part of Trust– Authentication– Issuing authorities (identity,

credentials, attrs)– Consider security workflows

• People seem to consider this solved

Existing work

• How far does existing work go?• Is it useful/usable?• Do they work together?• Do they meet the needs?

Existing work

• Lots known about local security– Applications running locally– But is isn't easy– And local systems are often “trusted”

• Lots known about secure programming– But many programmers are scientists

Existing Work (examples)

• caBIG (US cancer research)– Validation service, central trust service

• XtreemOS (EU funded secure OS)• IGTF work on trusted authorities

– Policies– Best practices for operation

Existing work (examples)• Policies

– JSPG (EGEE)

• Dynamic agreements– “Concertation”, “Orchestration”– TrustCoM, GridTrust

• Measure trust in projects– AssessGrid – WS-Agreement (OGF std)

Adapting Apps

• Adaptation libraries?• Can't tweak closed source• OS level (cf. GEMLCA)• Changing code

– Often done to make distributed– Gridifying is (often) not (much) harder

• Reuse is often difficult or expensive

Rethinking running apps

• Use TPM?• Consider escrowed data?• Running signed applications (like Java)• Trusted in service providers? (clouds,

grids)– “You can safely store your passwords with

us”– Banks do something like this

Identify the tradeoffs

• Security vs usability• Security vs performance• Revealing information: to service

provider (AUP), to VO (e.g. quotas), to other users (coordination, sharing)

“Paranoid” users

• Run apps on their own closed resources

• Do they want to change that? No.• Do we want to change that? ??• What is to gain?

– Interoperability– Improved security of existing resources

The role of deception

• Users– Run fake jobs

• Service providers– Honey pots

Is there a role for deception?

Consumes resources

How do we do it, then?• What are the requirements• What do we have and how does it fit?• Fill in the gaps

– Industry interest?– Juicy research topics?

• Who will/should benefit• Make it easy for apps writers/porters• Most effective way to make progress

How do we do it?

• Understand the risks– E.g. you secure your data but the user

takes it home on a laptop– ... or sells it to your competitor– Risk management framework– Help sell secure grid (or cloud) services

How do we do it then?

• Trust requires special attention– Are current policies sufficient?– Can we test or audit trusted

components?– How do we convince the end user?– Rewards/penalities

How do we do it then?

• Overcome the “security is hard” attitude– “We'll add it in later”– Locate a hole, e.g. data integrity or

confidentiality– Demonstrate? Don't put them off...

Which apps “most” need security?

• Apps with data security requirements– Permit workflow => security in depth

• Service provider– Calling external API => Trust

• Instruments– !!! => Flexible, manageable access

control