Upload
sydney-austin
View
219
Download
0
Tags:
Embed Size (px)
Citation preview
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