Senators Introduce a Bill To Protect Open-Source Software (washingtonpost.com) 35
An anonymous reader quotes a report from the Washington Post: When researchers discovered a vulnerability in the ubiquitous open-source log4j system last year that could've affected hundreds of millions of devices, the executive branch snapped into action and major tech companies huddled with the White House. Now, leaders of the Senate Homeland Security and Governmental Affairs Committee are introducing legislation to help secure open-source software, first reported by The Cybersecurity 202. Chairman Gary Peters (D-Mich.) and top ranking Republican Rob Portman (Ohio) plan to hold a vote next week on the bill they're co-sponsoring.
The Peters/Portman legislation would direct the Cybersecurity and Infrastructure Security Agency to develop a way to evaluate and reduce risk in systems that rely on open-source software. Later, CISA would study how that framework could apply to critical infrastructure. The log4j "incident presented a serious threat to federal systems and critical infrastructure companies -- including banks, hospitals, and utilities -- that Americans rely on each and every day for essential services," Peters said in a written statement. "This common-sense, bipartisan legislation will help secure open source software and further fortify our cybersecurity defenses against cybercriminals and foreign adversaries who launch incessant attacks on networks across the nation." Here's how the Peters-Portman legislation works, as outlined in the report: - It directs CISA to hire open-source experts "to the greatest extent practicable."
- It gives the agency a year to publish a framework on open-source code risk. A year later and periodically thereafter, CISA would perform an assessment of open-source code components that federal agencies commonly use.
- Also, two years after publishing the initial framework, CISA would have to study whether it could be used in critical infrastructure outside the government and potentially work with one or more critical infrastructure sectors to voluntarily test the idea.
- Other agencies would have roles as well, such as the Office of Management and Budget publishing guidance to federal chief information officers on secure use of open-source software.
The Peters/Portman legislation would direct the Cybersecurity and Infrastructure Security Agency to develop a way to evaluate and reduce risk in systems that rely on open-source software. Later, CISA would study how that framework could apply to critical infrastructure. The log4j "incident presented a serious threat to federal systems and critical infrastructure companies -- including banks, hospitals, and utilities -- that Americans rely on each and every day for essential services," Peters said in a written statement. "This common-sense, bipartisan legislation will help secure open source software and further fortify our cybersecurity defenses against cybercriminals and foreign adversaries who launch incessant attacks on networks across the nation." Here's how the Peters-Portman legislation works, as outlined in the report: - It directs CISA to hire open-source experts "to the greatest extent practicable."
- It gives the agency a year to publish a framework on open-source code risk. A year later and periodically thereafter, CISA would perform an assessment of open-source code components that federal agencies commonly use.
- Also, two years after publishing the initial framework, CISA would have to study whether it could be used in critical infrastructure outside the government and potentially work with one or more critical infrastructure sectors to voluntarily test the idea.
- Other agencies would have roles as well, such as the Office of Management and Budget publishing guidance to federal chief information officers on secure use of open-source software.
Uh huh (Score:2)
So no bipartisan legislation for these vulnerabilities as they creep up each month in closed source software? This seems like a congressional blowhorn bought and paid for by the software copyright cartels.
Re: (Score:1)
So no bipartisan legislation for these vulnerabilities as they creep up each month in closed source software?
Of course there is, it was that very legislation that formed the CISA in the first place.
The new legislation is to task CISA with evaluating open-source in the same manor as it currently evaluates closed-source.
Re:Uh huh (Score:4, Informative)
Given closed source software is generally tracked and audited for license compliance, it's well known what piece of software is in every computer. So when a vulnerability affects say, Photoshop, it's a simple manner in seeing who is affected because you have license management tools to know who has it installed, and there are audit tools to know who REALLY has it installed.
Open source software is a little less clear - it's sheer ubiquity pretty much means it's everywhere and because the license is so free, generally speaking it's not covered by any license management tool or auditing tool - after all, if you use say, VLC, you don't need to track how many copies of VLC you have deployed across all your computers. So you generally don't. Some IT departments might track it because they want it as part of their remote management tools, but given portable versions and such, this may be nigh-impossible to know for sure who uses it.
That's basically why. It's why log4j was particularly bad, because it was used literally everywhere, and no one had adequate knowledge of who or what had what version . Commercial software used it, and they didn't track that information either.
It's basically a way to not have stuff like this show up all of a sudden - if you supply a piece of software using open source, you better know what open-source stuff you used. Far too often people just toss it in without caring and when a vulnerability strikes, it's tough to figure out what's affected.
Or to take my example, say a department couldn't get access to Photoshop. They can't install it illegally, so they use The GIMP instead. But no one tracks The GIMP because it's not like the license limits you - you don't buy "1 copy of The GIMP" to use on 1 PC, you just... use it. And if IT doesn't let you install it, you use a Portable version of it. Now if a vulnerability affects Photoshop, you can run a simple inquiry to figure out where it's installed and who should have a copy. Not so much for The GIMP - you don't necessarily know it's installed, or who has it installed, or who runs it because it's not an asset that is tracked.
Re:Uh huh (Score:5, Insightful)
As someone who is a developer with closed source software, it is far easier for someone to disable SELinux, run all code as root or with elevated privileges, use multiple frameworks, and pay zero heed to security. For example, your precious "AES-256" is just using an AES key of all zeroes with 128 bits as a salt, and the password is just stored as a MD5 hash. Your previous 4096 bit RSA key? Might find it is easily re-generated from the serial number of the product. This way, a customer who locks themselves out, we can "magically" get their data back... for a huge fee. Think the developers care? They don't. Even if the company is sued into the ground, there are so many layers between legal and day to day activities that the chance of any consequences is zero. If a dev fails to make deliverables on marketing's timetable, they are going to get fired, and a H-1B taking their spot, so you bet your ass that security is something that at best, we might do some sham things just so marketing can tout encryption is present.
Security has no return on investment, and DevOps is about maximizing revenue. There is no place in it for security, other than the utmost minimum. We don't care, and every minute spent on security means explaining to the SCRUM master in the daily standup how we fail in life by not delivering marketing and the PM (who usually is the SCRUM master) what they want.
Why not just force the NSA (Score:3)
Re: (Score:2)
Good, if you aren't scared, you haven't been paying attention.
That does not sound like "protecting open source" (Score:3)
But rather "protecting FROM open source"
Re: (Score:3, Insightful)
normally anything a government does has unintended consequences and adds costs, thus causing higher taxes / more debt / money printing (inflation).
This is called, oh what's the phrase... oh yes that's it! Making shit up. That's what it's called.
Yeah yeah we know you hate the government and the government is evil. I assume that's why you're posting from the libertarian paradise of the congo or somewhere equally free of the nasty evil government.
Do it can have unintended consequences, and sometimes that's goo
Re: (Score:2)
How is that boot-licking commie bullshit getting upvoted? Slashdot used to have a smarter audience than this.
Re: (Score:1)
Let me know when you've grown up beyond "herp derp teh gubbmint si teh evul!!11one!11oneleven!1ONE1!" and we can have an actual discussion.
Re: (Score:2)
And the name of the dance is (Score:1)
Reducing Risk (Score:5, Informative)
...to develop a way to evaluate and reduce risk in systems that rely on open-source software.
This question was answered 25 years ago by Theo de Raadt and his team at OpenBSD, who put into practice a policy of rigorous code auditing and proactive security [openbsd.org].
Is it absolutely foolproof? Of course not, but OpenBSD has an exemplary record on security. Time and time again when vulnerabilities affected other software, the underlying flaw was found to have been previously fixed in OpenBSD. Their philosophy is that all bugs are potential vulnerabilities, not just bugs with proven exploits, and so have often prevented vulnerabilities by auditing for entire classes of bugs.
Re: (Score:2)
+ Mod parent up. Wait, you need to come up with a way to evaluate security risk? What do we pay you guys for? You're telling me you don't already know how to evaluate risk?
Well, I guess that explains a lot.
Re: Reducing Risk (Score:1)
Re: (Score:3)
This does not solve the underlying problem that people only examine the security of things they care about. OpenBSD is secure as long as you only use the included packages. The problem is for packages that people just use but no one actually pays attention to like log4j. OpenBSD does not care about it because it just doesn't matter to a basic OS install and there is no OpenBSD equivalent (nor should their be).
In fact, I don't know when was the last time I saw a system level exploit using a Linux/*BSD OS
Re: Reducing Risk (Score:3)
Re: (Score:3)
The problem happens when packages have no maintainers. I don't think anyone paid attention to log4j in years and then suddenly we have a panic when the inevitable happens. This is not the first time a non maintained project has burned a bunch of people this way.
Re: Reducing Risk (Score:4, Interesting)
The log4j project has plenty of maintainers. The log4j vulnerability was so bad because of all of the software using log4j required patches and were not easily applied. In many cases, the software using log4j was not being maintained. log4j is embedded in so many software packages, sometimes multiple times. Also, java is embedded in many appliances where you do not have visibility to the embedded software. The included log4j version was not something that was documented so it forced you to use other methods to even detect the prescience of log4j.
log4j is everywhere and nowhere at the same time.
Re: (Score:2)
Re: (Score:3, Informative)
What you're really saying is Ronald Regan was bragging about being a terrible president.
It doesn't do anything to fix it. (Score:5, Interesting)
The only thing this could even hope to do is help identify potential weaknesses. There is no funding to actually fix anything.
What this actually does is give businesses a free pass. When they get breached because of FOSS, now they can say, "well the government said it was safe!" and walk away.
If they are serious then this needs a NASA-sized annual budget and it should be paid for by raising corporate taxes.
Re: (Score:2)
What corporate lackey modded this down? Seriously, I didn't write anything that wasn't true.
Re: It doesn't do anything to fix it. (Score:1)
Software already analyzed (Score:3)
The NSA already knows all about the vulnerabilities in commonly used open source software: they analyze this on a continuing basis.
What should be done instead is for the NSA to maintain not only a catalog of vulnerabilities (that is, weapons), but the fixes necessary to close them, and a relationship with CISA to miraculously release them when it's in our interest.
(Which is not before they are exploited to our disadvantage.)
Instant Response To Known Vulnerabilities: an infrastructure (e.g. relationships with CISA, other agencies, and the Open Source community). Patch comes out the same day, courtesy of CISA. They would know who maintains the repositories for each item, in addition to the emergency patches being made available out of band.
Not much more book keeping than they are doing already, I imagine. But with a finger on the "Fix That" button.
For closed source, too. I imagine they do that as well, but I'm sure they do open source. NSA (and DARPA) are what brought you SE Linux, Tor, and other goodies. Also backdoored encryption and stuff, of course :)
No, shanks. Govt can CFAA it's ASS out of HERE. (Score:2)
The government sure knows how to go after security researchers, CFAA, make kids commit suicide by freeing documents.
No, shanks.
The FOSS community does a fantastic job without government oversight, annual reports, meetings and whatever other bullshit.
Government: You go focus on enriching yourselves, having no accountability, praying to your false orange god, and taking away rights from women, convicts, people within 100 miles of the border, anyone with cash, anyone without cash, and generally fuck off.
I use
Online payment processing solutions (Score:1)