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."
Just look at medical devices. They don't cost that much to make but have to go through a long certification process that needs to be paid back.
Same with software. Something like SOX, PCI or HIPAA will pop up to certify "secure software" and software that is patched on a regular basis and people will end up paying for it. And on top of that every piece of software will be "certified" on some platform, similar to a game console. If you run it outside of the certified hardware you lose the ability to sue.
You're all idiots if you think you will be able to run software on some of the ridiculous configurations I've seen in my time and expect vendors to pay for it when it breaks because of your stupidity.
... 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.
What you are seeing is the maturing of software engineering as a profession. A few hundred years ago if you needed surgery you would go to your barber. The reason for this was that they were usually in possession of the right tools. The medical profession eventually matured to what we have today, where a surgeon is a specialized physician. But that didn't happen overnight and lots of people died in the process. In fact, we didn't even have a theory of infectious disease until the 1830s.
The point is that right now hardware, including its firmware components, is oftentimes made without the involvement of a software engineer. It wasn't that long ago that software engineers didn't even exist and in time as the profession matures we will get to the point where developing a piece of hardware without the participation of a software engineer will be unthinkable. But we are not there yet.
An important side note is that there is a difference between a coder, a developer, a programmer, a software engineer, and several other specialized disciplines in the software arena. I think that a precondition to solving the problem identified by the article has less to do with things like development methodology (that is not central the problem at hand) and more to do with establishing minimum standards for some who claims to be a software engineer. For instance, a surgeon in 2017 has to meet vastly different minimum qualifications than a surgeon did in 1917. We didn't even have software engineers a hundred years ago, so who knows what it will actually looks like by the time the field really starts to mature.
Sorry, I stopped there, at "Even with the move toward more agile development and DevOps". What's the link, supposed positive here, between the two ?
Both "old" and "new" method won't never mean better software than the people using them.
Bad engineers using old method (V cycle ? Tons of documents ?) or new methods (you said agile, as in "get as many things done as possible, as quickly as possible, using shiny web app like Trello or Kanban-something" ?) won't make secure software.
May be with good engineers, you can achieve good results, whatever the method is.
More or less related : ISO9001 doesn't mean that the certified company makes good products, it means that it produces always the same quality, good or bad.
This may sound a bit like a troll, but I'd like to add that, since young engineers favor more agile methods, and considering the lack of experience, combined to the messy sensations I sense in agile methods, I tend to think that agile methods would produce less secure software ...
Totof
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!
We'll essentially get shrink-wrap contracts that basically say "This software can't do shit, if you use it regardless, sucks to be you."
In other words, what we already have.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
In spite of people confusing inflight entertainment systems with avionics, yes is is done all the time j. The aviation industry. Every piece of software that controls the airplane must be built to RTCA DO-178B/C design processes. Among other things, every input and output to every module is specified in the design process, and out of bound input responses are chosen. Then in writing the software, the inputs are checked, and then validated against random and maliciously crafted input. Bogus states are injected to ensure that each module identifies and recovers from an invalid state.
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.
Reading the article, it's all people with an interest in peddling solutions to the problem, naturally. This is a marketing paper.
Claiming that Software Engineers have "failed" at security is akin to claiming that police have "failed" at crime stopping crime. And the courts aren't going to suddenly start blaming companies for the actions of threat actors unless there is some representation that the products they're creating are unhackable.
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.
In addition to that, we have the most vulnerable OS being the biggest OS, and the Chinese building the Internet of things essentially open systems, so what would we do? Sue them?
It isn't to blame the victims here, but the ascendency of personal computing for the masses means that most computing devices are owned by people with very little idea of security. In a world where people click on random stuff they get in email, it's gonna be very hard to get any real security.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
If it's such a security issue, shouldn't it already be done correctly in the library or the logging system? These sorts of things is exactly what a developer shouldn't have to worry about. If the underlying system receives a string from a Log library, it should either be cleaned or the underlying system should clean those up.
Custom electronics and digital signage for your business: www.evcircuits.com
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.
"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..."
The developers aren't at fault. The people in charge have to be the ones to demand security. Blaming pros and cons on Agile or DevOps misses how companies really work. If the management puts security as a required feature, then it'll get added in even with Agile. Nobody should be dumb enough to allow bottom tier developers to set their own goals.
You also need management to actually hire security experts. A lot of failures come from having novices work on security (novices can mean those with decades of software experience but only a superficial understanding of security and zero academic understanding of crypto).
Because people want to do what they want and if the AI is getting in the way many people will find a way around the AI. Then complain when they get burned. That's just human nature and until you can change that I don't see a way to fix the problem.
Then you're not the person to tackle this issue.
Microsoft did (as mentioned above) glue their hardware together.
That fixes a lot of problems.
Microsoft will find a solution to security when it's cost-prohibitive to continue to ignore the problem.
It little behooves the best of us to comment on the rest of us.
If you think Fortify, AppScan, or Coverity will magically make your app secure, you are about as far from secure as you can get.
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.
It really depends on how big the company is, how often they get busted, and what exactly they are liable for. As it stands now, the average small company can go 20 years without an incident. The small company that skips on security can likely outcompete and outlast the small company that doesn't. Sure if they get unlucky and have a security incident, it could bankrupt them but the odds are in their favor that skipping security gives them a competitive advantage to the company that doesn't.
Uh, no. Given a choice between "use product from A and if there is a problem they are liable" and "use FOSS product and if there is a problem I am liable", who do you think is going to go with the second option?
You haven't read a EULA lately, have you? That's how it is now.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
The tiniest bit of actual research reveals that the issue with Therac-25 was actually the lack of physical safety interlocks which the software, written for an earlier model in the Therac line, assumed were present. Software developers were left out of the development of Therac-25 as the hardware and product guys assumed they could just use the existing software as-is and didn't bother to ask anyone who knew better.
The problem, then, was poor product (hardware) engineering and a series of lapses in judgment on the part of management.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
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
Yes, and liability stops with whoever put it in that safety-critical system without assurances from a third party that the software was fit for such use.
Similarly, a lumber yard is not liable if someone is particle board where high-tensile, fire-resistant, waterproof material is indicated.
Because there is no such thing as "AI". You obviously are not a programmer.
The FDA currently has very weak requirements for cybersecurity.
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.
Actually, I am a programmer (retired) and I agree with you that there is no such thing as "AI." The AI part was a dig at those who are delusional in that regard.
Still, you and I have the skill sets to write "play-like" algorithms that can single-step through an executable without allowing anything to actually happen.
If the code says it's going to start some shit, we can tell it, "No, you're not."
It little behooves the best of us to comment on the rest of us.
That is unmitigated nonsense. FOSS software is used, sometimes heavily, in industries where there is strong liability for security breaches, for example banking, medical, insurances, etc.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
LOL, HP Fortify, the tool that marks almost every line as a vulnerability to cover its own ass. It generates so many false positives that it is beyond useless. We'll just keep doing our own reviews. ...and if junk in your log manages to cause a hack, then it is not your software at fault. It is the log viewer software that is at fault. If that happens to be VIM or your shell, then yes, I boldly claim that is a bug in those pieces of software.
Well, we've both been at this a long time and I agree with you to a large degree.
The "intelligence" part of AI was initially equated with human intelligence.
Of course, an intelligent algorithm would commit suicide when it determined that Facebook was down.
So, while the buzzword remains, the definition of AI has changed to omit the unrealistic goal of being actually intelligent.
However, where we may disagree on a point:
I submit that a computer that can "mentally" make hundreds of thousands of moves in chess and pick the best move based on the outcomes of those several scenarios can also evaluate the consequences of going down a dark path via phishing or malvertisement, etc.
"Those who don't learn from history are bound to repeat it, and those of us who do are bound to predict it." ~ © 2017 CaptainDork
A lot of people died before fire codes became mandatory.
It little behooves the best of us to comment on the rest of us.
Solved the halting problem, there, did ya' pal?