Aspects of application security
Jens Jensen, STFC
3rd 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
social
manageability
users
usability
IDs
Science
Apps
attrs
data
results
authorities
mware
infra
availability
fabric
admins
time
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
Calling
API
Uploading
apps
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'
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”
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
• Service providers
– Run fake jobs
– 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