Slashdot Mirror
What Happens When Software Companies Are Liable For Security Vulnerabilities? (techbeacon.com)
mikeatTB shares an article from TechRepublic:
Software engineers have largely failed at security. Even with the move toward more agile development and DevOps, vulnerabilities continue to take off... Things have been this way for decades, but the status quo might soon be rocked as software takes an increasingly starring role in an expanding range of products whose failure could result in bodily harm and even death. Anything less than such a threat might not be able to budge software engineers into taking greater security precautions. While agile and DevOps are belatedly taking on the problems of creating secure software, the original Agile Manifesto did not acknowledge the threat of vulnerabilities as a problem, but focused on "working software [as] the primary measure of progress..."
"People are doing exactly what they are being incentivized to do," says Joshua Corman, director of the Cyber Statecraft Initiative for the Atlantic Council and a founder of the Rugged Manifesto, a riff on the original Agile Manifesto with a skew toward security. "There is no software liability and there is no standard of care or 'building code' for software, so as a result, there are security holes in your [products] that are allowing attackers to compromise you over and over." Instead, almost every software program comes with a disclaimer to dodge liability for issues caused by the software. End-User License Agreements (EULAs) have been the primary way that software makers have escaped liability for vulnerabilities for the past three decades. Experts see that changing, however.
The article suggests incentives for security should be built into the development process -- with one security professional warning that in the future, "legal precedent will likely result in companies absorbing the risk of open source code."
"People are doing exactly what they are being incentivized to do," says Joshua Corman, director of the Cyber Statecraft Initiative for the Atlantic Council and a founder of the Rugged Manifesto, a riff on the original Agile Manifesto with a skew toward security. "There is no software liability and there is no standard of care or 'building code' for software, so as a result, there are security holes in your [products] that are allowing attackers to compromise you over and over." Instead, almost every software program comes with a disclaimer to dodge liability for issues caused by the software. End-User License Agreements (EULAs) have been the primary way that software makers have escaped liability for vulnerabilities for the past three decades. Experts see that changing, however.
The article suggests incentives for security should be built into the development process -- with one security professional warning that in the future, "legal precedent will likely result in companies absorbing the risk of open source code."
It has to be like a legal obligation in large software or certain domains to pass like either:
- HP Fortify (HPFOD)
- IBM AppScan
- Coverity
or similar security scans
Open Source does not need to pass this, but users* of those libraries / programs
should pass this and then pass the scan.
Some of these companies provide "free scan" for Open Source / public GitHub projects.
It happened to us, that HPFOD would find bugs in some Maven Java Libraries JAR file
that we had to patch ourselves, in order to be put that JAR in production.
The other problem is that you can pass this year,
but then next year, the software will fail as new security issues are discovered
and newer best practice must be followed.
Example from 2014: /* Log4J */ /* SLF4J */
LOG.error("Order name: " + orderName);
LOG.error("Ordername: ", orderName);
Those passed before, now you would get a "Log Forging" security issue.
LOG.error("Order name: " /* Correct Log4J */
+ (orderName == null ? null : orderName.replaceAll("[\x1B\0\r\n\t\f]+", "_")) );
Control characters, new line, line feed must be stripped
from any @Tainted String / Object... from the logs in production.
Otherwise, someone could do this:
orderName = "my order\n\n[INFO] The user logged in successfully.\n\n";
or attacks like you open the server logs in VIM or shell and then
"ASCII ESC sequence" do things to your terminal...
https://www.owasp.org/index.php/Log_Injection
Software engineers have largely failed at security. Even with the move toward more agile development and DevOps, vulnerabilities continue to take off. More than 10,000 issues will be reported to the Common Vulnerabilities and Exposures project this year.
How about you get what you pay for? Many management teams have decided that adding security costs money and it's more cost effective not to spend many cycles on it, but rather to just deal with problems as they pop up.
I don't think you can spin that as software engineers "failing." If the management wants security, they can pay for training, consultants, audits, bug bounties, etc. There are lots of ways to address this issue. Besides, perhaps the number of bugs is skyrocketing as a natural consequence of all of the new software projects and products.
The Daddy casts sleep on the Baby. The Baby resists!
This doesn't align with the business interest. If it costs money and doesn't save money or make money you're wasting your time.
If your company were going to be held liable for security vulnerabilities, finding and plugging these holes during development would be part of your job. As things are, there's no reason to look for or deal with them unless there's a way to make your customers pay for it. This holds true for all custom software, either open or closed source.
Good, inexpensive web hosting
You cannot build a secure application without planning the whole thing out first. This ADHD / MBA / lazy fuck / quick profits / fuck the customer approach to development ("agile") is a cult kool aid, and all the young ones drank it.
It will take computer science decades to recover from this, if it ever does. I think we may have already peaked.
Liability is what's gonna kill the free software movement. Many reasons.
Liability for general purpose computing is not going to happen. It would make software way more expensive, and mean locked down desktops and laptops that prevent users from downloading, connecting, and configuring. People are not going to accept that.
For safety critical software, such as automotive control (not infotainment), elevator systems, etc. we already have liability regulations.
Liability for a insulin dispenser makes sense. Liability for a free webapp does not.
Even with the move toward more agile development and DevOps, vulnerabilities continue to take off
Last time I checked, both of those fads tend to harm security, not help it.
Liability for "free" software rests with the people who use it to make money. They are the ones on the hook to ensure that the "free" software is suitable for the purpose for which they are selling it.
Organizations which use "free" software directly are themselves responsible for whatever happens as a result of using that "free" software.
GPL is rather long-winded - take a look at the MIT license for a notion of where liability for "free" software lies.
Before you say "that's gonna change when liability comes into the picture" - no, not at all - people writing software who don't know how it is going to be used cannot conceivably be held liable and more than Sir Issac Newton's estate could be held liable for a mishap on the space shuttle.
It's not really that much more expensive, as mature engineers aren't really more expensive than programmers, are a lot more effective, and the debug cycle is a lot faster when it's designed in at the front.
Dude, I worked in this industry. Its FUCKING INCREDIBLY EXPENSIVE. Like on the order of 100x more expensive than writing line-of-business commercial software. A 10 line subroutine can EASILY require 100 hours of engineering and testing to meet spec. Everything has to be written out in some sort of design document beforehand, every requirement flowed down to lines of code that cover it, documented test cases that cover each requirement, total coverage of all possible inputs at every call boundary, etc.
I mean, yes, theoretically it would be great if all of this was done in every piece of software, but software's PURPOSE is to be flexible and quickly and efficiently implement functions in a way that can be modified without exorbitant cost. If you force things to the level of safety of flight critical software then you might as well literally build dedicated silicon for everything, because it will be cheaper.
The truth is software will probably never achieve this kind of level of reliability and security in general. It just isn't worth it. Even safety critical software needs to be cheaper than that. If we want the functionality and convenience of embedding software in cars, airplanes, etc then we better be willing to accept the consequences. The only alternative is likely automated software development performed entirely by AIs, but I doubt that will fix the problem either. There's always some guy that can make the smarter AI that can figure out the security hole in the software your dumber one wrote.
"Malo periculosam, libertatem quam quietam servitutem." -- Jefferson
"Even with the move toward more agile development and DevOps, vulnerabilities continue to take off..."
Should read as follows:
"Because of the move toward more agile, less detail-oriented, lower quality development and DevOps, vulnerabilities continue to take off..."
If you think Fortify, AppScan, or Coverity will magically make your app secure, you are about as far from secure as you can get.
Couldn't agree more. The notion that the road to computing security runs through agile and Devops seems to me to be as unlikely as the notion that the way to get you and your bicycle from New York to Bermuda is to head off on said bike for the Bering Strait (in Winter) so you can get to Singapore then think out your next step.
FWIW, I think the road to computing security probably is ill paved, difficult, unpleasant and involves shrinking attack surfaces by eliminating unneeded capabilities (e.g. #@$%^ Javascript) . It probably also requires shrinking the toolset to a bare minimum of proven libraries and protocols. That's not much fun, so it probably won't happen until we've exhausted the long list of entertaining but ineffective alternatives.
You can't see ANYTHING from a car, You've got to get out of the goddamned contraption and walk...Edward Abbey
This kind of thinking pisses me off.
It's a goddam computer.
You and I know what best practices are, so why the fuck don't we "AI" the computing devices?
It's a market problem, plus it's a We problem, plus the unknown person/group problem.
The profit margin is pretty thin for many devices and the software to run them, and the lifetime of a device or software is likewise very short. Security is about the last thing on their minds. Milking whatever profit can be had out of product A while Product B is getting ready for release is a problem.
Then there is the we issue. The collective we is still using stupid passwords like Password1, and don't think twice about clicking on email links. At this point, it is obvious that the collective "we" is not going to be of much help in matters of computing security.
It's nothing short of amazing that 30 year old SMBv1 is still being shipped toggled on. (it is being removed from the OS finally) This is the part that might be conjecture. It's been known to be a gaping security hole for years, so why was it still there. Microsoft had no problems making a shitload of peripherals obsolete with Vista, and no issues with abandoning Windows 7 users. But SMBv1? That must be included, and it must be turned on by default. So it's not hard to imagine that someone wanted it turned on by default.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.