The scientific enterprise in America requires enterprise class security to assure competitive advantage and efficiently advance discovery and invention. Across NSF funded activities there is pervasive and increasing concern with the availability, integrity, and confidentiality of scientific workflows, resources, data, and personal information. Threats include data loss and corruption due to archive failures or malicious attacks, release of private data maliciously or accidentally, or loss of computational or network capacity due to system software failure or compromise. The good news is that there are a number of common security solutions that support NSF researchers today however support for these is limited and often left to the individual development or project teams
This NSF-sponsored workshop will explore the potential for a cross-disciplinary Scientific Software Security Innovation Institute (S3I2) to address the protection, integrity, and reliability of research software, systems, and information. The goal of this workshop is to identify the needs for, and models of, an S3I2 to address secure scientific cyberinfrastructure in the United States. To accomplish this goal, the workshop will bring together representatives from NSF funded projects, researchers, developers, and resource providers. The workshop will cover the topics of: research security needs; existing tools, systems, processes and organizations that secure research activities and data; outstanding issues to be addressed in research assurance; and organization and operational models for a future security institute targeting the identified security needs. The workshop will result in an analysis of these needs and solutions and discuss the advantages of potential models for a S3I2 to address America?s research assurance needs.
Fromf 2010-2011, two workshops were held in response to NSF Dear Colleague Letter NSF 10-050 calling for exploratory workshops to consider requirements for Scientific Software Innovation Institutes (S2I2s). The topic of the workshop was the potential benefits of a security-focused software institute to serve the entire NSF research and development community. The first workshop was held on August 6th, 2010 in Arlington, VA and represented an initial exploration of the topic. The second workshop was held on October 26th, 2011 in Chicago, IL and its goals were to 1) Extend our understanding of relevant needs of MREFC and large NSF Projects, 2) refine outcome from first workshop with broader community input, and 3) vet concepts for a trusted cyberinfrastructure institute. Towards those goals, the participants of the 2011 workshop included greater representation from MREFC and large NSF projects, and, for the most part, did not overlap with the participants from the 2010 workshop. A highlight of the second workshop was a presentation by Scott Koranda of the LIGO project on the history of LIGO’s identity management activities and how those could have benefited from a security institute. A key analysis he presented is that, by his estimation, LIGO could have saved 2 senior FTE-years of effort by following suitable expert guidance had it existed. The overarching finding from the workshops is that security is a critical crosscutting issue for the NSF software infrastructure and recommended a security-focused activity to address this issue broadly, for example a security software institute (S2I2) under the SI2 program. Additionally, the 2010 workshop participants agreed to 15 key additional findings, which the 2011 workshop confirmed, with some refinement as discussed in this report. The major refinements from the 2011 workshop were: The NSF CI ecosystem increasing includes a number of "cloud" and other services provided by external parties. Any effort to increase the trustworthiness of that CI ecosystem must take those services into account in addition to software produced under NSF funding. The S2I2 must carefully balance providing a service unbiased towards any particular solution with keeping its staff suitably up-to-date through their involvement in projects, including the research and development of solutions. Adoption of orphaned software is a measure of last resort and the S2I2 should ideally avoid it if at all possible through planning and coordination. Assessment of software and services is valuable, but the S2I2 must be careful not to turn it into a purely bureaucratic function. A key goal of the S2I2 in providing leadership is the continuous building and distribution (through education, training and workforce development) of a body of knowledge on the topic of trustworthy CI. This includes successes and lessons learned from projects so that other projects can benefit from those. A key goal of the S2I2 in providing leadership is aggregating community needs and speaking on behalf of the community to external entities (e.g. InCommon, REN-ISAC). These refinements resulted in the following set of refined key findings: 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. A security-focused S2I2 should provide short-term support for orphaned security software deemed critical to NSF cyberinfrastructure projects. A security-focused S2I2 should perform independent software and services 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. The institute should not "own" software to avoid conflicts of interest between fostering adoption of that software and guiding communities to the best solution for their needs. Further the institute should take care not to allow their participation in software integration or development bias their future recommendations of that software. The institute should not provide operational security services or replicate existing services. 10. The institute should be governed in an open fashion that provides venues for stakeholders to discuss priorities and influence the institute’s activities as well as assures them of the institute not being influenced by any member’s baises. 11. The institute should be a synthesis point for expertise but not necessarily own all the expertise in-house. 12. The institute should coordinate its efforts and seek support across federal agencies including DHS, DOE, DARPA, and NIH. 13. The institute should have well defined relationships with the CMU Software Engineering Institute, InCommon, Internet2, REN-ISAC, and the XD TAIS. 14. Funding in addition to funds supplied by NSF for a security-focused software institute should be aggressively pursued. 15. The institute must document how it would gauge its own success.
