1. Second Scientific Software Security Innovation Institute (S3I2) Workshop October 26, 2011 Chicago, IL Randal ButlerVon Welch

2. Welcome 10/26/11http://security.ncsa.illinois.edu/s3i2/2

3. Thanks Deanna Spivey for logistics This material is based on work support by the National Science Foundation under grant number 1043843. Any opinions, findings, and conclusions or recommendations expressed in this materials are those of the author(s) and do not necessarily reflect the views of the National Science Foundation. 10/26/11http://security.ncsa.illinois.edu/s3i2/3

4. Introductions Introduction of Projects and Representatives 10/26/11http://security.ncsa.illinois.edu/s3i2/4

5. WORKSHOP GOALS 10/26/11http://security.ncsa.illinois.edu/s3i2/5

6. Workshop Goals Extend our understanding of needs of MREFC and large NSF Projects. Refine outcome from first workshop with broader community input. Vet concepts for a trusted cyberinfrastructure institute. Extended first workshop report with results. 10/26/11http://security.ncsa.illinois.edu/s3i2/6

7. Morning Agenda 9:00 Welcome and introductions (Butler, Welch) 9:15 Workshop Goals – why are we here 9:30 Recap of first workshop (Butler) 10:15 Break 10:30 LIGO experiences (Koranda) 11:15 Vision for the Institute and workshop goals (Welch) Noon Lunch 10/26/11http://security.ncsa.illinois.edu/s3i2/7

8. Afternoon Agenda Noon Lunch 12:30 Discussion 2:00 Checkpoint and phone check-in 2:30 Break 2:45 Continue discussion 3:45 Wrap up and Summarize 4:40 Phone check-in 4:55 Adjourn 10/26/11http://security.ncsa.illinois.edu/s3i2/8

9. Recap of First Workshop 10/26/11http://security.ncsa.illinois.edu/s3i2/9

10. First Workshop Process Survey circulated prior to workshop regarding cybersecurity needs. One day workshop in Arlington 10/26/11http://security.ncsa.illinois.edu/s3i2/10

11. Report URL http://security.ncsa.illinois.edu/s3i2/s3i2-workshop-final-report.pdf 10/26/11http://security.ncsa.illinois.edu/s3i2/11

12. First Workshop Representation Blue Waters Data Conservancy DataONE EGI FutureGrid GENI Globus GroupScope I-Chass Internet2 LIGO LTER nanoHub, HUBzero NEES NSF OSG SESF TeraGrid 10/26/11http://security.ncsa.illinois.edu/s3i2/12

13. Sixteen Recommendations Thirteen Dos and three Don’ts 10/26/11http://security.ncsa.illinois.edu/s3i2/13

14. Intellectual Leadership 1.A security-focused S2I2 should provide NSF and the NSF research community with security leadership and guidance. 2.A security-focused S2I2 should provide documentation, training, recommendations, and consulting to NSF cyberinfrastructure projects both on software security and security software. 10/26/11http://security.ncsa.illinois.edu/s3i2/14

15. Short-term Software Support 3.A security-focused S2I2 should provide short- term support for orphaned security software deemed critical to NSF cyberinfrastructure projects. 10/26/11http://security.ncsa.illinois.edu/s3i2/15

16. Assessment 4.A security-focused S2I2 should perform independent software security assessments. 5.A security-focused S2I2 should support security design reviews of MREFC projects or smaller CI development and integration efforts. 6.The institute should independently highlight/rank security software that NSF CI relies upon. 7.The institute should provide a security auditing service that includes vulnerability analysis and overall security assessment that validates security functions within a CI. 10/26/11http://security.ncsa.illinois.edu/s3i2/16

17. Should nots… 8.The institute should not develop software. 9.The institute should not do software integration. 10.The institute should not provide operational security services or replicate existing services. 10/26/11http://security.ncsa.illinois.edu/s3i2/17

18. Governance 11.The institute should be governed in an open fashion that provides venues for stakeholders to discuss priorities and influence the institute’s activities. 12.The institute should be a synthesis point for expertise but not necessarily own all the expertise in-house. 10/26/11http://security.ncsa.illinois.edu/s3i2/18

19. Relationships 13.The institute should coordinate its efforts and seek support across federal agencies including DHS, DOE, DARPA, and NIH. 14.The institute should have well defined relationships with the CMU Software Engineering Institute, InCommon, Internet2, REN-ISAC, and the XD TAIS. 10/26/11http://security.ncsa.illinois.edu/s3i2/19

20. Sustainability and Metrics 15.Funding in addition to funds supplied by NSF for a security-focused software institute should be aggressively pursued. 16.The institute must document how it would gauge its own success. 10/26/11http://security.ncsa.illinois.edu/s3i2/20

21. Break 10/26/11http://security.ncsa.illinois.edu/s3i2/21

22. LIGO EXPERIENCES 10/26/11http://security.ncsa.illinois.edu/s3i2/22

23. VISION 10/26/11http://security.ncsa.illinois.edu/s3i2/23

24. NSF CI NSF CI is tens of projects, across dozens of sites, with hundreds of implementers and tens of thousands of users. This is a significant IT effort! But cybersecurity today across this effort is haphazard. 10/26/11http://security.ncsa.illinois.edu/s3i2/24

25. Vision 1.Cybersecurity of NSF CI should not be limited by lack of available expertise. – All projects have access to knowledge about available cybersecurity R&D, technologies, best practices, policies, procedures, etc. – Lessons learned and successes flow freely between projects. 2.Community constantly advances state of the art in cybersecurity practice, drawing from own experiences and advancements of others. 10/26/11http://security.ncsa.illinois.edu/s3i2/25

26. The Challenge Cybersecurity expertise is not readily available to all projects. Big projects might be able to budget a cybersecurity person. – But there is not enough talent to be on all proposal teams. Small projects do their best. It’s scary to use something you don’t control. Tighter project planning, less discretionary funding limits flexibility. 10/26/11http://security.ncsa.illinois.edu/s3i2/26

27. Project cybersecurity needs Peak at project inception – Understanding needs, solutions – Typically first challenge to collaboration But occur cradle to grave – Changes in technology – Changes in community needs – Deployment and interaction with operations – Predictable and not Are not “one size fits all” – Different needs, cultures, collaborations, technologies 10/26/11http://security.ncsa.illinois.edu/s3i2/27

28. Range of needs Understanding trust requirements – Own needs, risk analysis and tolerance – Needs of collaborators, deployers, sites, etc. Choosing technologies – What works? What is interoperable? – What’s secure enough? What’s “enough”? SW development advice Independent assessment 10/26/11http://security.ncsa.illinois.edu/s3i2/28

29. Range of needs Understanding operational requirements – Authentication, logging, incident response, etc. Understanding changes, new options Helping with fires – Incidents, unexpected changes 10/26/11http://security.ncsa.illinois.edu/s3i2/29

30. What could be done to help? 10/26/11http://security.ncsa.illinois.edu/s3i2/30

31. Our History 10+ years of engaging CI projects on cybersecurity – LIGO, OOI, DataOne, TeraGrid/XSEDE, OSG, FutureGrid, iPlant, Globus, DES, IRNC, … – Working to understand need of operations. Advancing identity management Numerous workshops to build consensus. Bridging between communities – Internet2/InCommon, EGI, IGTF, DOE Roadmaps, papers, best practices 10/26/11http://security.ncsa.illinois.edu/s3i2/31

32. Small cybersecurity efforts CILogon, Bedrock – identity focused MIST – code review Secure Science Gateways – portal focus ISACs, CERT, etc. – targeted at security professionals Commercial consulting companies 10/26/11http://security.ncsa.illinois.edu/s3i2/32

33. What has been shown to work One-on-one with projects providing cybersecurity expertise. Helping determine needs and risks, explaining options. Evaluation/guidance of software, technologies. Creating a local expert within each project who becomes part of the larger community. Cradle-to-grave, planned and unplanned. 10/26/11http://security.ncsa.illinois.edu/s3i2/33

34. What has been shown to work Cross-cutting activities. Workforce development, training and documentation. – Development of new cybersecurity staff – Education on basics, trustworthy development, etc. Evaluating when external activities are ready to have an impact on the community. Establishing liaisons. Workshops to build community consensus. Documenting best practices, lessons learned. 10/26/11http://security.ncsa.illinois.edu/s3i2/34

35. Should not Make decisions, write policies, write plans for projects – Is a partnership, not an outsourcing – Inform, educate, provide examples, suggestions, etc. Develop, support, integrate software – Should interface with other appropriate CI projects/SI2 institutes Dictate a solution or level of security across the community 10/26/11http://security.ncsa.illinois.edu/s3i2/35

36. Primary Customers 1.CI Science projects – Understanding needs and options. – Help make informed decisions. 2.CI developers (SI2 projects) – Produce trustworthy CI with trustworthy design and coding. – Understand needs of cybersecurity in operational context. 10/26/11http://security.ncsa.illinois.edu/s3i2/36

37. Key Relationships Cybersecurity Projects: MIST, Bedrock, Gateway Security, REN-ISAC, Cybersecurity Summit – Make appropriate connections with customers Operational security at sites, facilities – Liaison to understand needs Cybersecurity R&D – Provide feedback, help transition to production Campus bridging – Campuses, Internet2, Educause Other agencies, countries/continents 10/26/11http://security.ncsa.illinois.edu/s3i2/37

38. Musts Technology independent, responsive to communities not any agenda. Transparent, all activities must result in public results. Be predictable, projects must know they can rely on services. Be flexible, able to address unexpected emergencies, quick needs. Be reviewable, clearly demonstrate value. 10/26/11http://security.ncsa.illinois.edu/s3i2/38

39. Metrics of Success Need to demonstrate customer satisfaction and good value. – In commercial space, it’s simple – people pay or they don’t. We need similar demonstration of value from customers if this is going to demonstrate merit. Food for discussion: Can it be a “totally free lunch” and have its worth judged? 10/26/11http://security.ncsa.illinois.edu/s3i2/39

40. DISCUSSION 10/26/11http://security.ncsa.illinois.edu/s3i2/40

41. Questions to Spur Discussion What are/were your needs and how would they fit into this vision? What would you add to first workshop recommendations? 10/26/11http://security.ncsa.illinois.edu/s3i2/41