1. Aspects of application security Jens Jensen, STFC 3 rd T&S workshop, NeSC 08-09 July 2008

2. 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?

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

4. Who needs it (stakeholders)‏ Data owner, controller Application owner Resource owner Funding body

5. Where? Grid? Clouds? Distributed computing? Desktop? From my perspective: –All of the above (probably)‏

6. Paranoid calculation... fE(d)=Ef(d)‏ or fE(d)=E'f(d)‏Linear E

7. manageability Science Apps IDs attrs fabric data results infra mware time social usability availability users admins authorities

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

9. Applications – APIs APIs –Web services –Grid –Cloud –Local –RPC Fine grained access control (architecture?)‏ Auditing Protecting data Trust in result

10. Access to Apps Licensing –License managers Commercial vs academic Payment and subscription models –Sustainability of service

11. 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?

12. Building blocks Long term signatures –Maintained against time –Changing identities –Changing crypto (vulnerabilities, apps support)‏ Algorithms

13. Trust in Service Provider Cloud model and grid model –Using remote resources, provided by ext'l provider Calling API Uploading apps Different security aspects

14. Accounting Account for resource usage –By user, VO –Currently wallclock, CPU Available (to user? VO? others?)‏

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

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

17. Levels of Assurance Part of Trust –Authentication –Issuing authorities (identity, credentials, attrs)‏ –Consider security workflows People seem to consider this solved

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

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

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

21. Existing work (examples)‏ Policies –JSPG (EGEE)‏ Dynamic agreements –“Concertation”, “Orchestration” –TrustCoM, GridTrust Measure trust in projects –AssessGrid – WS-Agreement (OGF std)‏

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

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

24. 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)‏

25. “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

26. The role of deception Users –Run fake jobs Service providers –Honey pots Is there a role for deception? Consumes resources

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

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

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

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

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