Could We Reduce Data Breaches With Better Open Source Funding? (marketwatch.com)

The CEO of Wireline -- a cloud application marketplace and serverless architecture platform -- is pushing for an open source development fund to help sustain projects, funded by an initial coin offering. "Developers like me know that there are a lot of weak spots in the modern internet," he writes on MarketWatch, suggesting more Equifax-sized data breaches may wait in our future. In fact, many companies are not fully aware of all of the software components they are using from the open-source community. And vulnerabilities can be left open for years, giving hackers opportunities to do their worst. Take, for instance, the Heartbleed bug of 2014... Among the known hacks: 4.5 million health-care records were compromised, 900 Canadians' social insurance numbers were stolen. It was deemed "catastrophic." And yet many servers today -- two years later! -- still carry the vulnerability, leaving whole caches of personal data exposed...

[T]hose of us who are on the back end, stitching away, often feel a sense of dread. For instance, did you know that much of the software that underpins the entire cloud ecosystem is written by developers who are essentially volunteers? And that the open-source software that underpins 70% of corporate America is vastly underfunded? The Heartbleed bug, for instance, was created by an error in some code submitted in 2011 to a core developer on the team that maintained OpenSSL at the time. The team was made up of only one full-time developer and three other part-timers. Many of us are less surprised that a bug had gotten through than that it doesn't happen more often.
The article argues that "the most successful open-source initiatives have corporate sponsors or an umbrella foundation (such as the Apache and Linux foundations). Yet we still have a lot of very deeply underfunded open-source projects creating a lot of the underpinnings of the enterprise cloud."

Comments

I doubt it

[Anonymous Coward]

Here, I'll solve this problem for you in one sentence, instead of a cloaked Ponzi scheme: strict legal liability for data breaches, extending *personally* to C-level executives of the companies at fault. Management generally doesn't care about security, and the only way to make them care is hitting them in the wallet directly. When they can't hide behind the corporate veil anymore and suffer direct financial consequences for their short-term thinking, even the most dimwitted MBA will start to wake up and take notice.

Re:I doubt it

[jellomizer]

In Business it is more complex then that.
To survive in the market you need to get your product out before the competition and/or you need more products. Failing to survive as a business is worse then the expense of a security glitch.

It is a chicken and the egg problem. We need a security commitment from the whole industry vs just one brave little company who would go out of business rather quickly. It isn’t an issue of bad programmers or management not wanting to give a quality product, but the restrictions on trying to make something good enough before someone else beats you to it.

It isn’t always with companies. Programmers working for costcenters in a different industry are pressured to get the advantage of the program out of development fast so the cost savings of the company can be realized. Or other cases esptwith not for profit is rapidly changing government rules (bipartisan) which are setup so you are always on the verge of being non compliance and not receiving the funding for the next quarter. So faced with being closed down or leaving a security flaw which you hope you can manage.

An outside group who can help maintain security may be able to help some issues. But unless customers are willing to wait for the product to be done right va fast. It isn’t going to happen.

Re:I doubt it

[ChatHuant]

We need a security commitment from the whole industry vs just one brave little company who would go out of business rather quickly.

A commitment from the whole industry won't happen. Fortunately, such a commitment isn't the only possible solution; the GP has already provided an alternative. Where the industry won't act voluntarily, legislation can force them to.

If breaches in security can be proven to be due to corner cutting, laziness or negligence (such as the Equifax fiasco) the Cxx managers of companies at fault should be made personally responsible. And not just monetarily, because they can push the expense on to the company and implicitly shareholders. If a CEO knew he risks going to jail or maybe lose the right to ever get a leadership position at any company anymore, you can be sure being first to market would suddenly become less of a priority.

As an aside, I believe making top company people more personally responsible for the company's actions shouldn't be limited to security; right now, top management can make bad or even illegal decision with relative impunity. The company will take the brunt of any penalties, shareholders will lose, while he'd still get his golden parachute. This needs to be fixed.

Re:I doubt it

[multriha]

The legislation will only happen in countries where the industry (as a big players or as a group) don't have enough influence over the legislature to keep such a thing from happens.

I don't know what countries could might this goal, but it's small enough to not matter, especially when companies will just make sure they don't legally exist in those countries.

It's cynical thinking yes, but pragmatic I'm afraid.

That's ignoring the decades of legal challenges if it actually did happen, or any fallout on open source projects when companies realize the most cost effective way to mitigate this risk is to push it onto software companies.

Re:I doubt it

[Anonymous Coward]

When they can't hide behind the corporate veil anymore and suffer direct financial consequences for their short-term thinking, even the most dimwitted MBA will start to wake up and take notice.

If they could be held liable they would simply get personal liability insurance and pass the cost through to the customers.

Re:I doubt it

[stephanruby]

But the parent you're replying to is suggesting to increase the expense of a security glitch.

We need a security commitment from the whole industry vs just one brave little company who would go out of business rather quickly.

But that's his point, isn't it? By targeting the C-level executives and making them liable for security breaches, then you're effectively solving the problem for everyone involved, from the small companies to the huge companies.

Re:I doubt it

[TheRaven64]

This might actually be the solution. Insurance has mitigated a lot of other risky behaviours. Insurance companies are (mostly) pretty good at quantifying risk and have a financial incentive to improve when they aren't. If they look at your company and say you're ten times more likely to suffer a data breach than your competitor, then they'll charge you at least ten times more for insurance. Eventually, it becomes a choice of spending the money on insurance or spending less money on improving security, at which point even beancounters can figure out that spending money on security is a good idea.

Re:I doubt it

[slashrio]

I hate to bring it to you, but it's the corporations that force laws upon the legislature, not the other way around.

Re: I doubt it

[jellomizer]

Issue 3? Do you just hate SQL, or do you have a real explanation why you shouldn't use SQL for real work?
Granted you can use SQL poorly which opens the door for SQL Injection Errors, However a properly parameterized command, and well optimized stored procedures, views, with proper access controls can offer a very secure method of protecting your data and preventing extra information from leaking to the outside world.

Two factors to weigh.

[king neckbeard]

There are two main factors to weigh here, IMO.

The first is that a lot of vital yet unsexy projects have inadequate funding and testing. Funding can help mitigate problems stemming from that.

The second factor is sysadmins being incompetent or not being given the tools, knowledge, and power to actually fix problems. Funding can't help that.

Re:Two factors to weigh.

[arth1]

Yes, the main problem isn't a lack of software[*]. It's that those who make decisions have no understanding of security, and their bosses in turn are looking at short term ROI.

[*]: Nor do I believe that funding would have helped if that were the cause. A great programmer doesn't become more productive if you toss more money at him. He'd be happy, and may deserve it, but likely you'd just finance more managers and get less done.

Re:Two factors to weigh.

[Kjella]

There are two main factors to weigh here, IMO. The first is that a lot of vital yet unsexy projects have inadequate funding and testing. Funding can help mitigate problems stemming from that. The second factor is sysadmins being incompetent or not being given the tools, knowledge, and power to actually fix problems. Funding can't help that.

I'd add a lot of attitude to that, developers that just bang it until it works. Management who says if it works, don't break it. And they go together hand in hand, if the new intranet is working we're done. The PHB and cheap Indian subtractor both think so. Firewall? Access controls? SQL Injection? URL guessing? View source? Never heard of it. And it'll keep running unpatched and out of support because it works until shit hits the fan and a scapegoat must be found, then the circle begins anew.

The problem is that for managers this usually works out for them, bonus for cutting costs and staying in budget. When shit happens they get a severance deal (because otherwise they'd air all the dirty laundry and all the accomplices) and pick up employment somewhere else. If the person who put the system in place even works there anymore. The incentives don't work on the individual level no matter how badly you punish the company. Not unless you got the CTO to sign off on a SOX-like compliance report with threats of jail time.

Re:Two factors to weigh.

[F.Ultra]

Exactly this yes. I.e the software that we supply to our customers are available as both deb or rpm repositories. At one time when we had a mandatory upgrade a huge chunk of the customers asked how they should proceed in order to get this mandatory upgrade... So for all the years between their initial install and this event they had not once run "apt update && apt upgrade" or "yum upgrade". People are insane is what they are.

No. Best practices are the only way.

[gweihir]

For the story: These people want to get rich on the current blockchain craze, nothing else. Ignore them.

As to the problem, best practices and liability are the only way. Yes, I am advocating jailing the CEO and CISO and possibly the board of companies that have large amounts of customer data stolen because of negligence. As an alternative, I would also accept insurance that automatically pays out $1000 to every custromer that has their data stolen (regardless of how much data it was and whether it was misused) and triple the actual damage to any customer that had their data stolen and can prove larger actual damage (losses + cost to fix) than $1000.

In order to be not negligent (note that I use simple negligence, not gross negligence) they will have to:
- Develop security critical software only with architects, designers and coders that are understand security (no more paying peanuts for coders...)
- Have external reviews of all security critical code by qualified security experts
- Have careful and adequate white-box penetration testing performed
- Not only fix the issued found in code-reviews and pen-tests, but also fix and investigate the root-causes, such as fire incompetent coders or outsourcers

Do this and the problem vanishes. The human race knows how to produce software that is extremely hard to break into. There are just no incentives to spend the money for it, and, despite my list above looking a bit bombastic, it would not actually be that expensive.

Re:No. Best practices are the only way.

[DogDude]

In the United States, corporations exist primarily to separate liability from ownership. As a result, people making criminal or negligent decisions inside corporations almost never go to jail or face any negative repercussions at all. Until the corporate structure is fixed, corporations will continue to do whatever they choose, with no criminal consequences.

Re:No. Best practices are the only way.

[AmiMoJo]

Anything to do with an "initial coin offering" is a scam.

Re:No. Best practices are the only way.

[gweihir]

Not everything, but it is a good general assumption and usually quite true.

Re:No. Best practices are the only way.

[TheRaven64]

Develop security critical software only with architects, designers and coders that are understand security

One of the big problems, and a large part of the reason that we're in this mess, is that a lot of security-critical software wasn't security critical when it was written. Here's a simple example: libjpeg. This library was written as a reference implementation of the JPEG standard, back in 1991. It was expected to be used to compress photographs from scans and render the compressed photographs on the screen. It's not security critical, because it's dealing only with data that it produced for the user. Then a few years later, the web appeared and gained img tags that could render JPEG images. Now, every web browser is taking untrusted data and passing it through libjpeg. One arbitrary code execution vulnerability in libjpeg and your web browser is compromised (or, in a modern browser, the renderer process that's responsible for one or a small group of tabs is compromised - not much help when that's your gmail tab and now the attacker can take control of your Google account and use it to install malware on your Android phone).

Worse, a lot of this software was written with speed at all costs in mind. The reference MPEG implementation is a wonderful example. It detected errors in the header by simply dereferencing the pointer and catching the SIGSEGV. It eliminated branches on hot paths and made the code run fast enough for realtime display on the slow computers of the time. I'll leave it to your imagination how that can be exploited when an attacker provides the video (of course, you were expected to get MPEG videos only from VideoCDs and other trusted sources, so this didn't matter). This mindset is still very common. Consider GPU drivers. If your card runs 1% faster than your competition, you'll sell a million more units. If you make it 1% slower but remove a security hole, you lose a million sales. Everything is fine until WebGL comes along and random web pages can provide programs to try to attack your GPU drivers (and no, the WebGL verifier is not helpful here, because it assumes that those 3 million lines of C/C++ GPU driver are bug free).

The hackers will get around it anyway

[Anonymous Coward]

If top tier companies like Sony can get pwned, not to mention government agencies, in reality, there isn't much companies can do. Security doesn't bring income, and you can throw your entire fiscal budget at it, only to get breached anyway because someone in receiving got a RAT from browsing the web on a machine there, and one privilege escalation vulnerability later, the attacker now has domain admin rights across the AD forest.

It really is a losing battle, as you can't win any engagement by defending only.

What you do as a company is sic your legal team on anyone who mentions weaknesses, do some PR, and if breached, state the above... the hackers are always one step ahead anyway with unknown 0-days, and move on. The good news is that the market completely forgets about hacks in a few months, so your stock price will be back to normal usually before the next quarter.

Re:The hackers will get around it anyway

[TheRaven64]

You can address that by limiting liability if they follow best practices. For example:

Was the thing that was compromised the latest version, exploited with a zero-day vulnerability? If so, lower penalty.

Was the thing that was compromised able to access only data that the component actually needed to function? If so, lower penalty. Higher penalties for anything that was leaked beyond the minimum that the attacked component needed to access.

Did you retain data beyond what the originators of that data would reasonably expect? If so, higher penalties if it's leaked.

The goal isn't to require everyone to have perfect security, it's to have penalties for below-average security, and use that as an incentive to push the average upwards.

Start giving a damn

[MoarSauce123]

The best way to prevent breaches is to start giving a damn. Stop collecting personal data on people, use encryption, run security audits, stay on top with patches, limit access.... all the standard stuff that gets ignored because it might cost a few bucks to hire someone to take care of it. Oh, and for sure making C-level managers personally liable for all damages caused by breaches will fix this issue right away. As soon as they potentially have to sell their helicopters and yachts to pay for damages they instantly will implement better procedures and make smarter decisions.

Re:Start giving a damn

[TheRaven64]

Security audits are not always useful. For example, I read the result of the security audit on Dovecot that Mozilla commissioned. They found three low-priority issues and one of those was not using FORTIFY_SOURCE. Here's the problem: FORTIFY_SOURCE does not catch any issues that cannot be caught by static analysis. If it improves security in your program, then it is only because you are not incorporating static analysis into your workflow, which is a really good way of writing insecure code.

No, we can't.

[Todd Knarr]

More open-source funding won't help reduce breaches. It'd be good to have more funding for development of the basic software, but most of these breaches happen because, despite a patch to fix the vulnerability being available, these companies treat simply don't apply the available patches. Until that stops being the case, more funding for the software will merely mean the breaches happen in different places than they would've otherwise.

Oh, and don't hold the sysadmins responsible. They're at the mercy of the instructions they're given. The people who need held accountable are the executives who classify IT security as a cost center whose budget needs minimized and breaches as a public-relations problem instead of a security issue and who refuse to give the IT people enough budget and resources and authority to apply fixes promptly.

No

[CaptainDork]

What do I win?

OSS had a fix for Equifax. They didn't apply it.

[mtraffanstead]

It's troubling that media can look at all the details of the Equifax story and somehow come to conclusion that OSS needs improving or is in anyway broken. OSS is certainly not perfect but the bug was identified, patched and publicized months before Equifax actually applied it. OSS did not fail here, incompetent security and* development teams did... at a company whose entire business is handling PII and Financial data. It's inexcusable and frankly criminally negligent.
* It also bugs me that I generally only see Equifax's security team called to the carpet for this. It's the development teams responsibility to have an ever-greening plan in place and regularly update their product. The security team should be the first line of defense against this and the application development team should have been the second. It's shocking how many developers I work with who think that libraries and frameworks are somehow "safe" and that I push regular updates only because "new-shiny".

Certification ?

[nehumanuscrede]

Is there a security equivilent of a UL Certification ?

If not, should we require one before a product can be sold ( for IOT stuff ) in the US ? Or a mandatory periodic security audit of corporate systems housing sensitive personal data ?

Development frameworks

[gbjbaanb]

When I was involved in high-security software development, we built the web sites around multiple layers each of which was secured and access was limited, reducing the attack surfaces. If a hacker ever got past all our layers to hit the database, then frankly, I wouldn't argue with them as they would be the NSA or KGB.

But then I started work with new Microsoft frameworks designed to make web building nice and easy (even though its a right over-engineered mess) and I see everything stuck in the webserver tier with full and open direct access to the DB via an ORM. All designed to be written as quickly and easily as possible with security a very distant concept to it.

and yet, said framework could easily split its MVC architecture up to a service and web tier, could put comments or a text file with security hardening information in, could partition the database into secured schemas and it'd be just as easy to write as the monolithic one but far, far more securable.

The current asp.net core framework almost is insecure by design, almost designed that everything is exposed if a hacker gets past the first (and only) level of security. All it takes is 1 zero-day exploit and all your data belongs to someone else. (and yes, other web frameworks are just as bad)

so yes, open-source projects could help - not by compiling a database or package manager of updates and security fixes, but by providing templates and architectures for project defaults that are based around layers of protection.

There will always be some weakness or flaw or bug in software, the only way to mitigate them is to work assuming they're are already there.

Re:No

[Required Snark]

Your prize is that your identity will be stolen. Again.

Re:No

[CaptainDork]

Fuck that.

I want a fur-lined dookey pot.

Not funding, quality of educated people

[AHuxley]

Its not a funding issue.
If money solved all computer problems a few top US consumer OS brands would have been the most secure OS ever.
They are not due the the low skill sets and the lack of education found in many of their workers.

Consider how an open source project responds to a person who shows security issues.
Do they have a person in place to accept the errors and communicate with the person who found the errors/bugs/backdoor/trapdoor?
That they can communicate back that the errors are understood, that they will be fixed and when. Thanking the person who found the errors and keeping them informed until the users get a fully patched OS.
Are all the errors are then worked and the results pushed out to the users?
Do the errors get fixed and the errors get noted internally but no actual patch/update for end users is released over a longer time?
Anyone looking can see the errors been accepted and listed online but nothing is done to secure the OS for the users.

That is all in the skill of the person and people who work on open source projects.
Some people are just responsive to errors and fix them for the users as a matter of pride, merit and skill. On time, every time as they care about their project and work hard.
Other open source projects are very happy to communicate, accept errors but have internal difficulties to actual patch their code so end users are protected in time.
Some projects just accept bug reports and sit on them as a part of a project to be fixed by someone later.

How to avoid this?

Stop looking to show a project has many different people working on it. If they cant keep up with error reports they are not helping in any way.
Find the best people to fix complex issues. Accept help from people based on merit and skill only. If a person cant code to a very good standard don't let your quality project become their educational support project.
The low skilled persons inability to learn/study and code to a very good standard is not your projects problem. Find much better people who can fix problems and who can work hard on the project long term. Find people who can show they know how to study and who actually have the needed advanced skills.
Stop just accepting people with few skills due to factors well outside actual needed skill sets.
The project will be well like by well educated people once they see the dedication, hard work and quality of code, error reporting support.
That is what matters. Good people who can code to a very advanced level.
Let the people with no or few skills find other projects to slow down. Keep them from altering your quality project.

No. Capability Based Operating Systems are needed

[ka9dgx]

Until we get systems like Genode or Hurd to the point where they can be used by most of us, and especially on servers, this is going to keep happening. The idea of trusting an application or service to voluntarily restrict its own actions is idiotic (at best).

Imagine getting a check from the bank of Windows... where after checking your ID very carefully, then handed you all of the funds for the account, and trusted you (the person delegated a small amount of the account holders money) to only take/remove the right amount..... that's what all the operating systems do. NONE of them require you to specify the capabilities to be handed to an application at run-time, but instead let the application do anything you can do, which is insane.

Capabilities are like having a cashier, who verifies the check, and only lets out the amount of money specified, and no more... if the balance permits. There's no need to trust the check-holder.

I give it about 10 more years until this insanity is resolved. ...So the prophecy is written, yet again.

Re:Short answer: No

[TheRaven64]

Note that in some countries (e.g. Germany) the agency responsible for protecting domestic computer infrastructure and the agency responsible for attacking foreign computer infrastructure are different. In the USA, the NSA has dual missions, which puts them in a difficult position because if they find a bug in X and X is used both by the US and North Korea (or whoever) in critical positions, they have to decide whether it's more important to keep their attack tool or prevent their enemies from exploiting the vulnerability.

One of the interesting results of the Snowden disclosures has been that the NSA and their rivals have found largely disjoint sets of vulnerabilities, so it's not even clear that if you fixed all of the things the NSA found that you'd be less vulnerable to attack from (for example) China or Russia.

Re:No. Capability Based Operating Systems are need

[TheRaven64]

Or you can use FreeBSD right now. Capsicum turns file descriptors into capabilities and as soon as you call cap_enter you lose all access to the global namespace and can only interact with external resources via existing capabilities (or ones that are given to you dynamically by another process).

You can also more or less view iOS as a capability system if you squint hard enough. They write ACLs dynamically to try to emulate a capability system (one of the motivations for Capsicum was looking at what Apple was doing with the TrustedBSD MAC framework and seeing how it could be done a lot more simply).

open source cryptocurrency ponzi scheme?

[najajomo]

"Developers like me know that there are a lot of weak spots in the modern internet"

There's nothing wrong with the Internet that needs fixing, the problem resides in certain computers at either end. Is this article an attempt to tarnish Open Source with some kind of crypto currency ponzi scheme?

Probably not

[Casandro]

Good "Open Source" funding leads to companies like Mozilla who, instead of trying to make the web better, mostly work on keeping the browser engine oligopoly alive.

A far better solution would be to have actual FOSS with the additional rule of being as simple as humanly possible. Simple code is shorter and therefore likely contains less errors. Less errors lead to less security critical errors. Also it's easier to maintain a 1k line program than a 20 Megaline program.

Considering that most things companies do are rather trivial, the far better way is to punish them for using overly complex solutions to their trivial problems.

Ahhhh wait....

[cjjjer]

Take, for instance, the Heartbleed bug of 2014...

Jog my memory but wasn't this caused by a bug in OpenSSL?

Also from what I have read the majority of "hacks" these days are basically phishing scams where people click on unsuspecting links or enter creds into fake web pages. The people behind it are just playing the numbers or doing specific targets (like the DNC hack).

Open source does not save us from ourselves in most cases.

Moving the question, the answer is no to both

[Excelcia]

This is a classic scheme of moving the question in order to obtain the desired conclusion. In this case, the real question they are trying to lead people to assume the answer to is "is the open source model to blame for security breaches". By essentially stating as a fact that it is, and then making the question "should we throw money at it to fix the problem", they are trying to get people to assume the first question.

No, the open source model is not the cause of security woes. Microsoft, with one of the most well funded set of developers on the planet, is the source of more and worse security flaws than anything else. It is true that Microsoft security flaws tend to be exploited differently, and not with single breaches that cause the loss of huge amounts of data. Microsoft security flaws are instead exploited with millions-strong botnets and massive infestations of ransomeware. The reason why Microsoft flaws don't cause massive single breaches is, of course, because their internet infrastructure software was so resoundingly awful that it was soundly rejected by everyone. This is because those that implement internet infrastructure are of generally above-average intelligence. I shudder to imagine if Microsoft had a significant presence in the current internet infrastructure.