Slashdot Mirror
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."
[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."
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.
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.
This is my signature. There are many like it, but this one is mine.
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.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
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".
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.
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.
I am TheRaven on Soylent News