White House Enlists Software Industry To Improve Open-Source Security (bloomberg.com) 63
White House officials are asking major software companies and developers to work with them to improve the security of open-source software, according to an administration official. From a report: The invitation follows the disclosure of a vulnerability in popular open-source Apache software that cybersecurity officials have described as one of the most serious in recent memory. In a letter Thursday, National Security Advisor Jake Sullivan invited major players in the software industry to discuss initiatives to improve open-source software security, the official said. Dozens of open-source software projects have become crucial components of global commerce and are mostly maintained by volunteers. The effort will start with a one-day discussion in January hosted by Anne Neuberger, the deputy national security advisor for cyber and emerging technology, according to the official. In the letter, Sullivan wrote that open-source software has accelerated the pace of innovation but pointed out that the fact that it is broadly used and maintained by volunteers is a "combination that is a key national security concern, as we are experiencing with the Log4j vulnerability," the official said.
Pay wages (Score:5, Insightful)
Talk all you want. Until there people are paid to audit and rework code it won't happen.
Re:Pay wages (Score:5, Insightful)
Too many organisations just take/use Open Source and contribute nothing back. If they all gave even small amounts the benefits would be great.
The trouble is that there is not a direct link between an Open Source user and the increase in security gained by that user. The result is that users (I'm talking about corporations who could afford to drop some cash to projects) see no point in helping - they just rely on others doing so; some are ignorant enough to say "It is free, I have no obligation to give any money.".
Government could help, just a small fraction of national defence budgets would be great and cost/benefit on national security be good; but again: why should one country donate when others are providing help (cash). The other problem is that proprietary vendors would complain of tax money helping their competitors.
Re: (Score:2)
No: it is short sightedness in corporations that cannot see how they might help themselves avoid a large cost (eg security fubar) by helping projects on which they depend. They are being penny wise, pound foolish.
Re: (Score:3)
Even software that one pays for has security issues. You are saying that the open source concept that openness brings security by allowing oversight is bullshit unless money is flowing - this is not the story I've been told for decades. Can you show an actual correlation between payments to open source projects and security? I'd argue that there isn't one.
The reality is that paid open source projects will still have these kinds of bugs and people using the projects need to consider and handle security in th
It's totally up to you. That's the freedom thing (Score:2)
You're absolutely right that tossing money at Microsoft won't get you security. Every month I do a briefing on the newest Microsoft vulnerabilities, and every month there are 60-100 news ones. Similarly, if you blindly write a check to a randomly-chosen foundation, with no instructions on how it should be used, most of it probably won't end up in the security budget just by random chance. On the other hand, if you pay someone to do security code review, you'll almost surely get code review, which will impro
Re: (Score:2)
I was responding specifically to Alain's comment:
> No: it is short sightedness in corporations that cannot see how they might help themselves avoid a large cost (eg security fubar) by helping projects on which they depend. They are being penny wise, pound foolish.
You are correct, if I decide to independently hire a security expert to go over a project then there could be security improvements. That is not the same thing as saying contributing cash to open source projects improves security generally.
How
Re: (Score:2)
> You want free as in beer and I want free as in freedom - otherwise you are just another vendor
Did you intend to type that the other way around?
I said you are free to do whatever security testing or analysis is appropriate for your use case, or get me to do it.
You said you don't want to pay.
I said you have freedom, you said you want free beer (you want to pay nothing, contribute nothing, and have it magically certified for your use case).
Open source is not magic, it is freedom. It means you CAN audit t
Re: (Score:2)
> you said you want free beer (you want to pay nothing, contribute nothing, and have it magically certified for your use case).
I did not ask for certification, I did not ask for anything. What I did say is that when I have to pay for open source, and when open source developers tell me that I cannot have security unless I pay for it, then open source is just another vendor and the choice between commercial software and open source is purely philosophical. There is no evidence that shows that paid open
Re: (Score:2)
> then source is just another vendor and the choice between commercial software and open source is purely philosophical
You've either forgotten or don't know that freedom and choice are a thing.
The ability to do what you want with the software matters. Not just philosophically - vendor lock-in can cost millions, and also make security impossible. Try upgrading the encryption on your car key fob that opens the doors and maybe starts the car. You CAN'T make any upgrades, any changes. That matters.
What you s
Re: (Score:2)
Open source does not prevent vendor lock-in. For all I know my car key fob does include open source software - that does not mean that I can change it. I know for a fact that my the infotainment system in my car runs Linux, I still cannot change it (without some serious work that will void any warranty). Throwing money at open source software does not change that, and does not bring more security.
Even when I pay you your software will still have bugs. Money is no panacea here.
"We're from the government..." (Score:2)
"... and we're here to help".
Re: (Score:2)
Google does that.
Re: Pay wages (Score:2)
Just realize that commercial software isn't better, but it's harder to find potential attack vectors in it.
Re: Pay wages (Score:2)
Your company already pays you a wage. Change GPL to include a mandatory minimum number of hours volunteered to open source projects. That would allow employees to force employers to comply. Employees in the US are basically powerless and companies have a fiduciary responsibility to be greedy and not give back.
Re: Pay wages (Score:1)
Re: Pay wages (Score:1)
Re: (Score:2)
I would say some of the issue is that open source developers don't see themselves as accountable to anyone because they 'open source'. Why would someone pay large sums of money to anyone who will tell you they will get to your issue if they think it is important enough. Meanwhile the developers will keep working on some 'new feature' they think is important. And even if a company pays someone to implement something or fix a potential security flaw, it won't be merged into the code unless the open source de
Re: (Score:2)
I would say some of the issue is that open source developers don't see themselves as accountable to anyone because they 'open source'.
You are quite correct. I'm one of them. I'd give a giant "EAT SHIT" to anyone who wants me to code for free then add features or fix bugs they want ... because why again? Did you pay fuck all for what you got? No. Did you contribute anything more than whining and pontificating about what is to be done with these incorrigible coders? No. In short, FUCK YOU PAY ME [youtube.com]. Oh, and by the way, in the meantime while you are digging in your wallet, I'd also like you to know that I'll be cobbling together what ever half-
Get serious (Score:4, Interesting)
If they wanted to get serious, they would pay open source developers on a 1099 basis, based on contributions/submissions (accepted) to various projects.
The govt can pay welfare recipients for doing nothing and/or breeding babies. It can pay actual contributors to society's technical infrastructure as well.
Re: (Score:1)
If they wanted to get serious they'd expand SSI to pay everyone a UBI, paid for by taxes on the wealthiest and a reduction in military spending. Taking care of people's needs reduces crime.
Of course, we have to do similar things across the whole world in order to reduce internet crime, since it's global... good luck!
Re: Get serious (Score:3)
Re: Get serious (Score:2)
UBI, contrary to what its proponents claim, won't take care of people's problems. It could in the short term, but in the long term it just increases the money supply without increasing the availability of resources. Money just enables trade, it doesn't produce anything, nor does it make people more productive.
By the way, you've probably never noticed this, but UBI experiments always seem to end up with the same result: People either quit their jobs, they just remain unemployed if they already didn't have a
Re:Get serious (Score:5, Informative)
Many eyes make all bugs shallow if there are enough of them, if they are actually engaged in looking for bugs, and if they have the necessary skills.
FOSS is not the only realm of human endeavour in which glamour and interest attach mostly to new and exciting work. Few people would wish to spend their precious free time poring over the sources for old pieces of code that are used everywhere and taken for granted.
That is a problem that extends to all software. It is so much easier to write new software and "roll it out" than to make quite sure that it works properly, and is secure and reliable.
"Technical debt" - vast, and getting bigger all the time. (Like other forms of debt).
Re: (Score:1)
The many eyes argument died with Heartbleed.
Re: (Score:3)
It didn't either, except for people who constructed a straw man argument in their head about how many eyes were supposed to prevent security failures, when the actual argument is that they reduce them.
Without access to closed source code bases to be able to perform comparative analysis you can't make any intelligent estimates of relative safety, so it remains one of the great unknowables, proven neither wrong nor right.
Re: (Score:2)
Re: (Score:2)
All design defects - even undocumented ones - are shallow as well if enough people read the source code. That doesn't mean the developers will fix them though, even defects as serious as the ones that made Log4J 2 trivially exploitable. Some very serious defects look like features, even if it is impossible to use them safely.
Confusing code and data, for example. Surely some people find it convenient that developers can inject lookup expressions in attacker controlled data the same way that attackers can.
Re: (Score:2)
I think the idea that this behavior should be preserved for convenience or backward compatibility is (now, finally) a thing of the past among the Log4J people though.
Fact of life... (Score:4, Informative)
Re: (Score:3, Interesting)
Re: (Score:2)
IT really has become like any other urban infrastructure.
Some parts of it are new and shiny and comply with all the latest guidance and engineering sophistication. Some parts are sort of new, but have a bit of kludgery applied at the edges.
The rest is a duct tape and bailing wire mess, a spaghetti that really can only be thrown out and started over.
And it's not just code, but whole environments which run more or less by the grace of god and are so fucked up nobody is willing to tinker with them (or pay the
Re: (Score:2)
Look at it this way, would you rather have everybody roll their own? Log4J is successful because it solved a need and worked. Your points about poorly being maintained are not accurate however, this was a feature that was introduced and not fully thought out.
Re: (Score:1)
Re: (Score:2)
Re: (Score:3)
It's a good open source project. It just had a vulnerability that someone found.
The real problem we face is a serious design problem. We have absurd monolithic applications like Apache that are overprivileged and outside any reasonable scope. The original reason for this was to streamline the processing of requests when we had single-threaded processors. Despite the overabundance of processing power and memory available, software has not shifted toward become small isolated worker processes that do one job and pass on the results. Software flaws are inevitable part of computer prog
Re: (Score:2)
Not quite all our software. Browsers are pretty good at compartmentalizing stuff.
The bigger issue is that when problems are found and an update is required, many people are too scared to change a working system. If an upgrade is even compatible, it's still a big risk and likely means downtime or out of hours work.
Re: (Score:2)
Browsers aren't privileged system services but rather applications. I would argue that compartmentalization was only needed after JIT compilation and other features made page content a credible threat. You don't need extreme isolation measures when using a JavaScript interpreter which means it's really a self-inflicted wound.
As for the issue of updating, this is a non-issue because properly isolated system services don't even exist for Linux, they are all monoliths running as highly privileged users.
Re: (Score:2)
You forgot the hype curve and multiple scramble fixes that go along with it. Update your POMs folks and push it.
Re: (Score:2)
Unfortunately, Log4J 2 did not fail due to the presence of any kind of bug. It failed due to a defective design that the developers refused to fix for years. It is still defective, and no one in their right mind should use it. Why should anyone trust software from developers with a fatal case of confusion between code and data?
Who think that scanning and evaluating attacker controlled data for lookup expressions is a convenient design feature? In engineering terms, they are insane, and the software in ver
Re: (Score:3)
I should back pedal on that. It appears that the Log4J 2 developers have had a change of heart due to recent events and really are trying to prevent any kind of substitution in untrusted data, including thread context data, and may have succeeded as of version 2.17.
Re: (Score:1)
Please mod the parent up!
Fiduciary responsibility (Score:5, Interesting)
The big issue this incident has exposed is the failure of risk management. The reality is that adopting widely used, popular tools like Log4J present a very low barrier because it is free as in beer. That appears to absolve its users/adopters of their fiducial responsibility, but should not. How often have you faced the need to present a business case to use Open Source software. Rarely if ever.
So where does the fiduciary responsibility fall here?
The Log4j development team are unpaid volunteers, this is the case with many Libre projects, but everybody expected them to drop everything, put their lives on hold and deal with it, and find a solution, but what about the organisations using it? This is despite the fact that free and open source software licences have a very explicit As-Is clauses in them.
Re: (Score:1)
Re: (Score:2)
That appears to absolve its users/adopters of their fiducial responsibility, but should not.
This is despite the fact that free and open source software licences have a very explicit As-Is clauses in them.
What the hell are you going on about? "Fiduciary" makes absolutely no sense in this context, but I will just roll with it in the spirit of Christmas.
If you are a commercial software vendor with support contracts with your customers, and you use open source software for your product, you bear the burden of support. You agreed to the as-is terms of the open source license and your users pay you to fix problems.
If you are selling support contracts for your software, you bear the "fiduciary" burden of your co
Re: (Score:2)
#1 Fiduciary responsibility is absolutely relevant to being a professional software developer. That includes working on internal development projects.
#2 Log4J and the Apache technology stack are open source development tools, not COTS and the are used extensively internal development project. I have worked with Java for two decades on very large scale projects, with UK Telco, UK Government Agencies, a UK Bank, a national UK supermarket chain and several E-Commerce.
#3 My argument is that project management s
Re: Fiduciary responsibility (Score:2)
Re: (Score:2)
You are projecting and the rest of your comment shows you have little or no first hand familiarity with the Java/Apache technology stack or its use in Enterprise systems. The majority of Java developers are very familiar with Apache Java stack. The majority of that work is internal development projects not packaged solutions.
This is not a unique to Java, I have seen the same issue of uncontrolled technology proliferation first hand with LAMP, Python and Microsoft development shops.
Re: (Score:2)
The only way to solve that is to
1. Pay people to contribute fixes, ideally the same ones who look for the bugs in the first place.
2. Pay people to create easy update mechanisms for popular open source projects. Stable APIs or compatibility shims.
enlists? (Score:1)
Ask their TAO group then (Score:4, Insightful)
Aak their Tailored Access Group who sits on exploits for the nsa/cia/fbi.
Anything else is pretending you dont already know the attack vectors.
Re: (Score:2)
Re: (Score:1)
Haha. (Score:2)
White House is now a software development outfit?
Re: (Score:2)
The White House need not be software engineers to advance system security any more than Eisenhower had to be a civil engineer to envision an Interstate Highway System or Kennedy had to be a rocket scientist to envision putting a man on the Moon. Al Gore didn't have to *invent* the Internet to be instrumental in making it happen and making it available to civilians.
The power to get funding for something is not a thing to be underestimated.
Would Google or Apple be very keen? (Score:2)
After all they are awaiting to see if this administration will prosecute them for anti trust (timing / effort depending on DOJ's budget, according to one of the earlier stories here). They can always hint at making some big open source related investments if the government stops following up on the anti trust stuff.
Otherwise they can always find bugs and fix them for internal use while not releasing their findings to the general public.
Too evil? Or giving them ideas?
G D and T Software Testing (Score:2)
consider.
as a part of security.
employ software testing methods
not paywalled (Score:2)
You can find this article in many places without a paywall, but here's a version that has a tiny bit more info: https://siliconangle.com/2021/... [siliconangle.com]
Worthless (Score:2)
These guys want to reach out to just a few top ppl, but really are not that interested in solving these issues.
With a trivial bill, they could cut much of the cracking that is occurring.
Read between the lines (Score:2)
When the government asks to "improve security," what it really wants is a back door.
Stop talking and get to work (Score:1)