1 / 41

Second Scientific Software Security Innovation Institute (S3I2) Workshop

Second Scientific Software Security Innovation Institute (S3I2) Workshop. October 26, 2011 Chicago, IL. Randal Butler. Von Welch. Welcome. Thanks. Deanna Spivey for logistics

karen-mcneil
Télécharger la présentation

Second Scientific Software Security Innovation Institute (S3I2) Workshop

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Welcome http://security.ncsa.illinois.edu/s3i2/

  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. http://security.ncsa.illinois.edu/s3i2/

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

  5. Workshop Goals http://security.ncsa.illinois.edu/s3i2/

  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. http://security.ncsa.illinois.edu/s3i2/

  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 http://security.ncsa.illinois.edu/s3i2/

  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 http://security.ncsa.illinois.edu/s3i2/

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

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

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

  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 http://security.ncsa.illinois.edu/s3i2/

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

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

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

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

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

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

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

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

  21. Break http://security.ncsa.illinois.edu/s3i2/

  22. LIGO Experiences http://security.ncsa.illinois.edu/s3i2/

  23. Vision http://security.ncsa.illinois.edu/s3i2/

  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. http://security.ncsa.illinois.edu/s3i2/

  25. Vision • 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. • Community constantly advances state of the art in cybersecurity practice, drawing from own experiences and advancements of others. http://security.ncsa.illinois.edu/s3i2/

  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. http://security.ncsa.illinois.edu/s3i2/

  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 http://security.ncsa.illinois.edu/s3i2/

  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 http://security.ncsa.illinois.edu/s3i2/

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

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

  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 http://security.ncsa.illinois.edu/s3i2/

  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 http://security.ncsa.illinois.edu/s3i2/

  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. http://security.ncsa.illinois.edu/s3i2/

  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. http://security.ncsa.illinois.edu/s3i2/

  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 http://security.ncsa.illinois.edu/s3i2/

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

  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 http://security.ncsa.illinois.edu/s3i2/

  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. http://security.ncsa.illinois.edu/s3i2/

  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? http://security.ncsa.illinois.edu/s3i2/

  40. Discussion http://security.ncsa.illinois.edu/s3i2/

  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? http://security.ncsa.illinois.edu/s3i2/

More Related