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

Second Scientific Software Security Innovation Institute

(S3I2) Workshop

October 26, 2011Chicago, IL

Randal Butler Von Welch

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

Welcome

10/26/11


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/11


Introductions

• Introduction of Projects and Representatives

10/26/11


WORKSHOP GOALS

10/26/11


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/11


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/11


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 Adjourn10/26/11


Recap of First Workshop

10/26/11


First Workshop Process

• Survey circulated prior to workshop regarding cybersecurity needs.

• One day workshop in Arlington

10/26/11


Report URL

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

10/26/11


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/11


Sixteen Recommendations

• Thirteen Dos and three Don’ts

10/26/11


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/11


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/11


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/11


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/11


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/11


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/11


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/11


Break

10/26/11


LIGO EXPERIENCES

10/26/11


VISION

10/26/11


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/11


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/11


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/11


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/11


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/11


Range of needs

• Understanding operational requirements– Authentication, logging, incident response, etc.

• Understanding changes, new options• Helping with fires– Incidents, unexpected changes

10/26/11


What could be done to help?

10/26/11


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/11


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/11


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/11


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/11


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/11


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/11


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/continents10/26/11


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/11


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/11


DISCUSSION

10/26/11


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/11

Documents

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