Schmidt Futures - and, in particular, Ashwin Ramaswami - prepared this report on the advisability of setting up a federal OSPO. I reviewed it before it was published, so Sustain got a byline, which is nice. 
2 Likes
I had no idea that this was report was about OPSOs. There is going to be a lot of problems for ALL OSPO++ orgs if they are funded under the auspices for improving cybersecurity outcomes, but then people realize that is only 1/3 of the purpose of these organizations.
1 Like
I also agree that thereās too much emphasis on cybersecurity. I believe the economic value that OSS generates should be the primary focus.
We should have enough data by now that shows open-source is a unique investment, more like this: āā¦ was conservatively estimated to give a 200% return on investment, in addition to creating a āthriving, mutually beneficial ecosystemā of individuals, government agencies, and private entities. Moreover, public support of OSS has been shown to lead to substantial increases in jobs in the IT sector.ā
On the other hand, security is probably an easier sell 
I also believe āgrantsā funding schemes wonāt scale much; that would be too bureaucratic and slow for the dynamic open-source ecosystem.
Still, as someone who has been advocating that we should finance open-source through public money, itās a fantastic initiative. Letās see how it will progress.
2 Likes
Itās also a shame all the endorsers are men. And someone really needs to make a new cartoon: https://xkcd.com/2347/
1 Like
Yes, 2x. and here are a few more characters so I can post
This is an interesting discussion. I am not sure the opening premise is precise enough to be actionable:
"Open source software is widely relied upon, but poorly supported, putting our national security at risk."
In fact there is a wide range of support levels. They vary by project purpose significantly. For example, I would argue the LINUX Kernel is nearly the opposite of āpoorly supportedā, as are many open source projects that fall into the category of critical infrastructure. I am not saying the myriad of open source communities cannot do better, and be more systematic, but I would argue that framing open source software as a āsingle thingā or category of software make it hard to know where to direct resources.
The CHAOSS Projectās (a Linux Foundation Project) Risk working group has developed a series of āminimum viable metricsā after lengthy discussion of the complex relationships between software dependencies, software vulnerabilities, and security risks. We will be summarizing our discussions and the āminimum viable metricsā related to them shortly.
The reportās call for resources may be premature, as I donāt think most OSPOās or open source communities yet have enough information to help make generalized, strategic decisions.
Instead, from a security perspective, IMHO it may make sense to help organizations ā especially those controlling critical infrastructure, or information āhoney potsā ā to harden their security at the network layer. All software is less vulnerable if we have sufficient network engineering resources in front of them. In my own experience Iāve secured systems that have software with unknown vulnerability levels using techniques like DMZās and IP address filtering.
Ultimately, I support the recommendations in the report link, but would like to see movement in the direction of precise goals like I suggest above. Surely NOT only those specific thoughts, but those of others who are experienced cybersecurity experts. Good network layer security can be deployed relatively swiftly for critical infrastructure and information āhoney potsā while we figure out the best strategies for managing software risk. My metaphors are often strained, but I suggest we first build a network layer fort, and then polish our cannonballs.
Sean
1 Like
Hi Lawrence,
I just made a rather detailed response. On the topic of OSPOās specifically, Duane OāBrien at Indeed.com is one OSPO leader Iāve spoken with who has a clear vision of the questions OSPOās need answered in order to meet the software side of what I think is a much larger risk profile than open source software.
In fact, I might argue that in many cases proprietary software poses an even greater risk because those vulnerabilities are much easier to keep out of the public spotlight. Its kind of like (tortured simile this time) saying that your risk visibility is greater in a black box than a glass box. That doesnāt pass my personal āsmell testā.
Both proprietary and open source software benefit from network layer gatekeeping. If I was spending government money right now, I would spend a lot of it there.
Sean
Alyssa:
Waitā¦. What?! Have we learned nothing about how many blind spots all male panels have?! I am simultaneously shaking my head, laughing, and crying.
Sean
I donāt know, weāve learned a few things. Iāve learned how easy it is to ask for my name to be removed.
Thanks, Alyssa. Iām not perfect and I hadnāt noticed.
The most important thing Duane is doing is getting consensus about the metrics that need to be tracked/governed.
Excluding Banks, Defense and a few other regulated industries, few companies have Chief Risk Officers. BUT, CIOs measure risk all the time.
1 Like
HI Lawrence:
Indeed (pun intended), Duane has done a great deal to help us sort through the sometimes confusing, overlapping, and unclear jargon that different computing specializations use to discuss software security, vulnerability, and dependency in open source.
A lot of the synthesis that CHAOSS has done, and is in the process of translating into a clear(er) articulation of the issues at hand have been through Duane, Kate Stewart, David Wheeler, and Sophia Vargasās commitment of time, and relentless pursuit of getting these issues to the point where they are clear enough to support coherent discussion and strategery.
Since I like to repeat myself, Iāll add that we have a much greater understanding of the risks of open source than we do for proprietary software. I think when it comes to questions of securing critical infrastructure and information this discussion needs to account for the black box and the glass box. IMHO.
Sean
1 Like
From the open source software security perspective, I think one of the most impactful investments is in setting up free scanning and testing services for open source. One of the earliest of these was the Coverity Open Scan tester, which is widely used by open source projects. A more recent but also very popular example is the Google OSS Fuzz project. There are services that scan for CVEs in dependencies, services that scan for ātypical or well-knownā coding errors, and systems that look for https on web site and signatures on download files. They require the bare minimum investment and effort by the developer and yield a stream of useful test data. Any free automated service like this that is tailored to doing repetitive work for the developers will have tremendous payback. So, I recommend looking at the opportunities for helping the developers meet any emerging new standards for secure software. If you want all these projects to have SPDX files, how about an SPDX āgeneratorā or ācheckerā like the web cookie applets everyone uses?
To the point about the risk of insecure deployment of open source, I remember a document NIST wrote years ago, recommending how to deploy BIND 9 software in a more secure manner. This document included explicit guidelines for locking down the operating system, limiting file access, etc. As far as I know, in itās current form this is a javascript checklist with instructions published by the US Defense Information Agency (DISA). Anyway, the point is, this kind of explicit instruction/documentation is something that can be compiled by someone outside of the open source development team - and someone who has developed one can leverage the experience in developing others. This is another highly-leveraged activity that āsomeoneā could fund.
I am not arguing that these activities are necessarily better than others that have been suggested, but I think they are contributions that open source projects would welcome.
Vicky Risk (Product Manager at isc.org)
1 Like
The same regulation that is coming out that will require SBOMs will also address proprietary software. It will require vendors that do business with the US government to notify them whenever there is a security breach. It might do more than that, but Iām not sure.
Honestly, we havenāt gotten the jargon down yet ā weāre closer, but there isnāt buy-in from vendors and different communities.
2 Likes
A lot of really great points here. My favorite: Checklists work. In my experience most professionals responsible for deploying core infrastructure for critical (safety, national security, medicine, etc.) systems use them with profound discipline. When I worked on therapeutic medical devices, we tested every potential system state, for example. Some systems have to be as deterministic as possible, but we obviously do not need to, and cannot afford to apply that standard to all software. (And, yeah, we definitely used heavily modified open source projects).
Regarding tools, my opinion is evolving toward deploying an array of tools, and applying the same standards for all software. Here, I am thinking about these issues as requiring redundancy [simple example: 737 Maxās standard single airspeed sensor], and recognizing that the ~20 different tools weāve looked at on the CHAOSS project to date, including the ones you mention, all have blind spots.
Pragmatic aside: Itās my personal opinion that there is a difference between solving the problem, which I would like to be the goal, and hiring a tool vendor to deflect management risk associated with software (open source and otherwise) risks. Most organizations will, I suspect, hire a vendor; I just donāt think that will ever be enough. If we also harden network infrastructure in ways I suggested in a prior response, and deploy a repertoire of tools aimed at dependency and vulnerability risks using different strategies, I think the goal of securing the worldās most critical systems is achievable within a certain tolerance for failure because, seriously, this is an arms race. We wonāt win them all.
Of equal concern to the goal of securing open source software (IMHO) are little pieces of proprietary software that act as known unknowns in many cases. And what about hardware? FPGAās are increasingly common in the field, especially at the end of the wire. Is it necessary in some cases to deploy multiple sensors from different vendors/projects?
IMHO, open source software plays a role, and we have challenges to meet. And if we meet them all, I am not convinced the overall security threat to critical systems will be solved. I am reasonably convinced they will not be.
Finally ā¦ Some questions for others ā¦.
- Since Iām not a networking security expert, but Iāve used sophisticated networking configurations to protect critical systems over the years, I am most curious to know if that community shares my intuition/belief/experience/perspective that committing resources to hardening that layer around software is the first place dollars should flow.
- I am also curious if others view the unknowns of proprietary software as a security policy issue that governments should address in parallel with discussions about open source software.
- Finally, putting on my tinfoil hat, its no secret that government agencies have back doors built into many systems. Iām curious what the relative risk to critical infrastructure is when those back doors are hacked by bad actors. Especially in comparison to the challenges we are generally aware of.
Like most people here, Iām spending my time and energy looking at the open source software component; securing open source software. This is necessary, IMHO, but not sufficient. The cybersecurity threat matrix, even from a cursory, conceptual point of view, doesnāt put open source software at the top of my list of things to commit the most resources to right now. Some, yes. Definitely.
Sean
1 Like
One of the primary reasons for these vulnerabilities is that OSS is often maintained by volunteers who do not always prioritize security
What is the responsibility of these guys if it appears that they are spreading misinformation, and OSS is often maintained by volunteers who do always prioritize security? The incentive should be done on supporting those voluteeers, instead of making an impression that they should be replaced in the name of national security. I donāt want to bring this topic, but in Belarus people are detained daily for any dress in red and white colors, and that goes in the name of national security.
2 Likes
Hi all, thanks for the feedback! Thanks, @awright, for pointing out the issue with endorsers; thatās helped us be more intentional in our process for endorsers in the future.
@abitrolly, The proposal was meant exactly to find a way to support these volunteers by directing more public money towards them. Sorry if that wasnāt clear and weāll work to make that clear in the future!
We picked this proposal because it was already a Cyberspace Solarium Commission recommendation and we thought that helping advance an already proposed way to fund OSS would be good low-hanging fruit.
Regarding the proposal itself, the language was passed in the House NDAA, but it didnāt make it in the Senate NDAA and didnāt make it through conference committee. However, weāve had conversations with Congressional staffers who are now more convinced that securing OSS is a good thing, so hopefully there will be more interest for initiatives like this in the future! At Plaintext Group, weāre also looking to fund or help make a reality ideas in this vein (novel or innovative methods that would provide systemic improvements in OSS sustainability), whether theyāre technical or policy-related.
2 Likes
About Cyberspace Solarium Commission, is this the report that you mention?
Building A Trusted ICT Supply Chain
Sounds fantastic; please keep us posted!
1 Like
Thanks for the heads up. I will be the second to ask for the proposal text. The document referenced by @coni2k is quite hard to impossible to read for me, so I just skimmed through it, and havenāt found any references to people or individuals. If thatās the text that is staffers is discussing then talking about open source sustainability, then I donāt see how it makes sustainability for open source people any better. It is quite logical to assume from it that text that staffers would prefer corporations with open core models over individuals who support open source movement. Although in my opinion the defense strategy in open source should be the same as of internet - make the knowledge, distributed, widespread and ubiquitous, so that good cases are transparent and are hard to take down.
Great news! How do we keep them engaged?
1 Like
Anatoli is right. IDK why many people just assume that public officials that work for the government should be the most brilliant and wise individuals than the rest of the civilians. I donāt feel safe when senators like Lindsey Graham decide the public budget assignation for securing OSS.
Anybody remember the Anti-Encryption Bill?