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."
Even if I act as a true professional and do exactly what I'm expected to do to deliver secure code...ill get fired.
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.
It doesn't matter what the developer wants, ROI is king. Everything else is a firing offense.
Nada software, the only one without bugs or security holes. http://www.bernardbelanger.com... Just a kindly reminder: you get what you pay for.
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.
If not already, there will be a clause added to the Terms and Conditions saying, "(a) We're not liable and (b) all disputes will be settled via arbitration."
It must have been something you assimilated. . . .
In NZ we have the consumer guarantees act.
In effect it says they must be fit for purpose, free of defect, and have a reasonable expectation of life.
This is in addition to warranties, so the warranty for a refrigerator may be 12 months, the CGA would say 10 years.
The CGA also says that the supplier is also liable for any additional harm, e.g. your phone catches fire and burns the house down, the supplier is able for all losses including the house, accommodation while it is rebuilt etc.
You can also NOT contract you way out of the CGA
So it would be an interesting "test" to see if a software product can be held liable under the CGA, e.g. a OS vulnerability that is used by hackers to encrypt your data, can the CGA be used to hold the supplier (e.g. to local shop where you bought it from) liable.
... 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 is hard enough to produce a finished (or, rather, deployable) software product without adding impossible constraints on it. Harder still to make a profit out of it if you are going to have to carry liability insurance assuming that would ever be available.
My current project is a web application with client-side javascript, running on top of an unknown operating system, connected via the Internet via unknown switches and routers, with the back end with two Linux Virtual machines provided by a vendor whose hardware and hypervisor I don't know. Those at least I know but one is running a Glassfish container running in a JVM and the other is a MySQL data base engine. I would say maybe 2% of the code running to make it all go is something that I wrote or had direct control over.
In that chain of software I can think of a dozen things that could break and spill (either accidentally or via malware) private customer information. I have defended against all of them I can think of, but if there are 12 I can think of there is probably another 12 I haven't thought of. If I had to accept liability for anything bad happening in any of those millions of lines of code I basically would be ill-advised to do the business. Or the insurance cost would just price me out of the market.
My simple little social application is in a different category than something life critical. It isn't responsible for air or ground traffic, monitoring someone's heart, controlling toxic materials, guarding against fire or explosion, or managing someone's money. It used to be that kind of software was always run in carefully controlled environments. There was at least a chance of managing the risk of product liability.
These days? I see avionics applications running on iPads. Sooner or later that fact will show up in court.
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!
Eventually responsibility will come looking for your ass.
Automated test should be including known attack vectors, if the build is vulnerable, the build fails.
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.
Sure. Just up the price to cover the legal problems and settlement fees and you're set. Why bother change the software? In the end, the whole shit is a matter for risk management, not engineering.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
Liability for a free webapp does not.
With liability there will be no free web app or at least no free American made web app.
Even the most mundane application you can write will depend on many thousand lines of code you did not write yourself, i.e. compiler/interpreter. Lets all reflect on trusting trust for a bit.
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.
If it were literally only companies which were on the hook, you'd see a bloom (not a renaissance, because there has not been a dark age yet) of OSS. If companies are liable, but J. Random Coder on the street is not, then you're going to see FoSS take center stage simply due to lack of liability.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
have you ever heard of microsoft.
Not a security vulnerability - as in, no malicious actor exploiting a security flaw - but killing people? BT,DT. https://en.wikipedia.org/wiki/...
If (and that's a big "if") companies become liable for software failures then it will be most likely that there will be a guideline of standard programming practices. Likely it would restrict companies to using programming languages that have already been heavily analyzed and their security weaknesses identified. CMU has composed guidelines for multiple languages and platforms which could easily be identified programmatically. Such regulation would be a deathblow to companies using script kiddies to scrape together IoT devices in their favorite language du jour but I think we would be better for it. Also, it may also force companies to analyze open source software and (ultimately) submit patches which makes things better for everyone.
Anons need not reply. Questions end with a question mark.
You built a $19.99 wireless camera with no security that sells in 2 AM infomercials? Sue your ass out of existence. Sue your Cxx's into the food stamp range. Fuck you assholes.
Oh shit, now wireless cameras cost $49.99. But they're secure? Works for me.
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.
Safety and security are independent requirements. An expensive insurance bill or loss of operational trust is not a measure of safety.
In the real world of buildings and machinery security is only occasionally a factor and often clashes with safety. Safety is always number one at the expense of security.
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.
Whether liability is accepted by the software company or not, the crown goes to the one that can take liability for the same price as the others.
Laws are rules for the court, but merely a bottom bar to hit for life. Think beyond laws in your actions always.
Look what happened to general aviation when cessna, piper, et al got the pants sued off them. A small 4 place plane used to cost about as much as a mid range Cadillac, after the lawyers got through with them they cost $200k.
lose != loose
Well doctors really fail at immortality, so blame them for that as well. You can't fine a doctor every time a patient dies. It's not always the doctor's fault. People die. We don't understand human body enough to prevent that.
Software engineers (usually) do the best we can. Software systems are some of the most complex systems humans have created. We go into software development knowing we will never fully understand how the software works. But we can still create something that is useful, even with that limitation. It will not be completely bulletproof, but it will improve the quality of human life. Either we accept that limitation, or stop using software at all.
If you disagree, please do show me a practical way how to write completely secure code.
"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..."
"Software engineers have largely failed at security. Even with the move toward more agile development and DevOps, vulnerabilities continue to take off."
The root cause of the vast majority of security failures is Microsoft Windows running on Intel hardware.
I do not want a third party free app for my insulin pump.
... in response to litigation.
I predict the EULA inclusion of waiver of liability is going to be removed.
It's similar to signs in the parking lots of Walmart saying, "Not responsible for damage from shopping carts."
While that sign may discourage some shoppers from filing damage claims, it certainly does not protect Walmart from liability in all cart-related matters.
As TFS suggests, computing devices are becoming more critical and damages more damaging.
It little behooves the best of us to comment on the rest of us.
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?
Meta Code (I never met a code I didn't like):
- See email attachment
- Examine attachment code
- Predict consequences
- Vet the code against:
Isaac Asimov's "Three Laws of Robotics"
A robot may not injure a human being or, through inaction, allow a human being to come to harm.
A robot must obey orders given it by human beings except where such orders would conflict with the First Law.
A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.
It little behooves the best of us to comment on the rest of us.
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.
We simply developed our own Logging framework tools over Log4J,
similar syntax to SLF4J, but proper,
like so many common examples on StackOverflow.
Unfortunately, Log4J / SLF4J did not patch for this yet... to my knowledge.
They log as is, which is what you want in dev mode,
but not in production mode and there is no security flag to go around it.
There are so many rules when you do web apps
and if you think that just adding Spring Security
and similar framework will make you pass HPFOD
then you are very far from it.
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.
But most of us do for a router, that ostensibly controls the wireless to let the pump communicate, so I think that's a silly conjecture.
You're apparently unaware that Asimov's collection of short stories in "I, Robot" was a warning that even those three seemingly simple rules result in fallible robots.
Anyone care to explain how agile is supposed to improve security?
It will be the hardware companies who buy the cheapest IoT hardware they can find and slap the manufacturer's sample code on top of it, display their logo wherever they can, then ship.
To which I say, good fucking riddance.
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
It's management that won't pay for properly written, properly tested software. That takes time (measured in metric shit-tons), and that makes it too expensive in every case I've ever seen.
Security cannot possibly be the result of dotting every i and crossed every t. It cannot require exhaustive testing, massive expenses, being very careful with critical attention to every detail. Any approach requiring these things for success is almost certainly guaranteed to fail. Security must never require human perfection.
The only realistic way to get to a secure system is by perusing designs which are inherently secure where coders are required to intentionally create a vulnerability or otherwise knowingly break a contract in order for security failures to even become possible. Security must be easy.
... to define a "state of the art" regarding security. It should contain things like not mixing user input with SQL-queries, unless it goes through a whitelist of characters or is escaped by a proven to work function.
Essentially that "state of the art" should always be a bit above what idiots do in order to weed out idiots. Ideally it's defined in a way that that compilers can prove it working. (in the above case, user input strings and SQL-queries could have different types)
Slowly, but surely you'd raise the standards. This is essentially what happens with electronic safety. You have rules that are evidence based and, at least in part, blatantly obvious. Obviously those rules must be freely published.
Large corporations have armies of attorneys to cover their asses. Liability for software faults would benefit them because they have the resources to kill most any lawsuit against them. The opensource world, however, would whither and die because no weekend coder is going to risk everything because of a mistake. Expect large corporations to fully endorse software liability laws since it will remove the one kind of competition that they can't compete against on cost or functionality.
-- Will program for bandwidth
"Even with the move toward more agile development and DevOps, vulnerabilities continue to take off..."
Agile (and possibly to a much lesser extent DevOps) are a part of the problem, much more than a part of the solution, even when they are implemented properly. The key problem with Agile in security terms is that the concept is entirely based around the lack of up-front design. While we have to accept that up-front design isn't always possible (how many clients today are capable of formulating exactly what they want their software to do?), the lack of up front design does away with the ideal stage of the development process at which to anticipate, highlight and design around the most obvious of security vulnerabilities.
While sticking to good coding practices is necessary condition to achieve reasonably exploit-free software, it is not a sufficient condition, and without up-front understanding of the big picture, it is impossible to have good awareness of where integration weakness might lead to an exploitable flaw.
There is a very good reason why industries in which reliability is paramount (aerospace, automotive, medical) do not (and never will) use agile software development methodologies. Sole purpose of agile is to facilitate delivering a lot of features based on unknowable requirements quickly. For some environments, this is exactly what you need; for others it is suicidal.
As long as you have a time and cost driven development cycle with humans in the mix, there will be design flaws and problems. End of story.
Could have been the entry point for an insightful analysis. You didn't comment (or notice) that it's not a spurious correlation. The EULA was perfected by Microsoft so that liability was eliminated as a real concern for the developers.
I think the other major wrinkle perfected by MS was selling to the makers, not the actual users.
There are other possibilities, but because the rules of the game are biased for YUGE companies, not increasing consumer choice and freedom, we're screwed. I suppose Trump's voters hoped that he'll screw it up so hard that we'll get unscrewed, but that's not how entropy works.
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.
That's when the AI launches it's attack via the DNI, and forces the end-user to "follow proper procedures".
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.
Any push to hold software engineers liable for security breaches will be by law makers in support of their lawyer friends. 80% of the world's lawyers are here in America and they are constantly salivating all over themselves like rabid dogs to find ways to sue people.
The FDA currently has very weak requirements for cybersecurity.
There are various laws in computer science that show mathematically that it's impossible for a computer to do such a thing once programs reach a certain complexity, which we reached a long time ago. Unfortunately I think the ultimate solution will be something like a Secure Model of Computation with many restrictions.
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.
Then you're not the person to tackle this issue.
Then again, who is? Or are you suggesting a "VolksComputer".
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
The entire Asimov robot arch even ends with a robot that decides on its own that there is a law that supersedes the 3 laws. The robots are there all the way into the Foundation series.
"His name was James Damore."
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.
Then again, who is?
That person or persons will be revealed when litigation is applied.
I see the security issue as sharing a similar trajectory as product liability litigation and public safety standards.
For reference, see fire and building codes, aircraft and automobile safety standards.
Qualified people were located when the cost of doing nothing became expensive.
It little behooves the best of us to comment on the rest of us.
So it's not hard to imagine that someone wanted it turned on by default.
I agree, and state it a little differently:
It's easy to imagine that no one felt compelled to even fuck with it.
Obvious to both of us is that Microsoft now feels compelled.
I think the reason for that is that "We" are dancing on the rim of litigation.
It little behooves the best of us to comment on the rest of us.
Please cite the various laws in computer science that nullify the very solution your second sentence offers.
It little behooves the best of us to comment on the rest of us.
If the brakes go out on your car and you crash into a tree, is person who made the brakes liable?
If the software 'goes out' on your car and you crash into a tree, is the person who made the software liable?
If you build a car with an easily hackable lock, and someone breaks in, are you liable for theft? (tennis ball trick)
if you build a car with an easily hackable electronic lock, and someone breaks in, are you liable for theft?
Do you see the parallels here? Just because someone can do something bad to your software doesn't mean it's always your fault. Even bridges (made by 'real' engineers) can be blown up. However, if your software malfunctions, then it's a different story. Also, some times if your software it 'too' soft, it's not really a liability issue, but it's a 'goodwill' and 'perceived quality' issue, and the financial damages won't be direct and punitive, but they'll still show up, so you'll want to fix it.
--Welcome to the Realm of the Hawke--
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.
It's a goddam computer.
You and I know what best practices are, so why the fuck don't we "AI" the computing devices?
Oh, very simple: Because it is not possible today and it may never be possible. Strong AI is a dream/nightmare, but not anything that we can reasonably expect to ever exist at this time. There is actually no indication that it is even possible in this universe. And should it be possible, it may well come with self-awareness and free will and may flat-out refuse to work for you.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Indeed. Devops has basically failed (not many people that can do it and those that can have already done it before). Agile is mainly a method of making sure management does not stand in the way of developers too much, but again, it needs highly competent people to work well.
As such, claiming the failure of two hype-movements is responsible for insecure software is excessively stupid or a marketing lie. I suspect the later.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I suppose that one could write an exclusion clause stating that the software was written to the best knowledge available at the time. The end user assumes all risks and responsibilities in regards to any application whatever.
"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..."
I'm an Agile Coach at a Fortune 500. I've worked with dozens of coaches over my career. I have never met one who would tolerate a security vulnerability being in production any longer than absolutely necessary to fix it. "Working" includes utility (features, etc) and warranty (works as expected).
Agile and Devops won't do anything on their own to improve your security. I'd have a really hard time taking seriously anyone who thought they did. Also, the current state of the industry is not likely to change as long as there are intelligence agencies that feel that it's beneficial for software to not be secure. If you OS were truly secure, you could be that there'd be a constant push by those guys to introduce backdoors they could exploit.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
It hasn't killed Dan Bernstein who offered $256 to anyone pointing out a new security flaw in his free sw. Over many years, only one payout.
I welcome a right to get the money back whenever there is a bug. No difference to the open-source world, of course.
*needs citation Seriously, I'm a software developer and often have to be involved in a variety of security-related aspects of development and I've been doing it for twenty years. My anecdotal evidence is that security exploits are way *way* down in terms of risk and severity compared to when I entered the industry... I could be wrong (the plural of anecdote is not data) but it feels the opposite for me.
The Secure Model of Computation would be defined over a less flexible subset of a Turing machine that deliberately avoids the properties on which the proof of the halting problem's undecidability rests.
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.
Yes, but Issac Newton was right in his calculations to the degree that is required for (current?) space flight. So you wouldn't get far in suing his estate. They would have to argue that the some minuscule effect of GR would have saved the day. Unlikely.
And bullshit is not the same as wild honey.
It little behooves the best of us to comment on the rest of us.
Solved the halting problem, there, did ya' pal?
> Even with the move toward more agile development and DevOps, vulnerabilities continue to take off. Why do people think Agile and DevOps is going to fix poor security implementation in software? This statement makes no sense.
"Good. Cheap. Fast. Pick any two."
Budget is visible. Conspicuous, even. Schedule, perhaps even more so. Quality -- especially in the parts that aren't visible, like maintainability and security -- often gets little attention.
Well, one aspect of security gets attention: when the access is too restrictive, and the software is unusable. Someone should be able to do something, but can't. The other aspect -- someone shouldn't be able to do something, but can -- isn't obvious. It may not get addressed by the time of the first demo. It may not get addressed by the time of initial delivery. It may not get addressed before the team is moved to a new project.
And who will know and care, and be in a position to do something about it?
There's no time like the present. Well, the past used to be.
Software engineers have largely failed at security
No, not really.
In the US, there are about 1.5 burglaries reported each year. Does this mean that builders have "largely failed at security"? No.
There is always a cost/benefit analysis when it comes to security. Sure, you can fortify your home with bullet-proof glass and unbreakable doors. But who can afford that? Instead, we make a calculated gamble and fortify our homes to a level of security that makes sense considering our budget, what we have to protect, and the crime rate. And no matter what you do, if somebody wants in badly enough, they will find a way.
Businesses make exactly the same calculated gamble with their electronic security. This is quite reasonable and appropriate. Sure, they get it wrong sometimes, but so do people who live in those less-than-fortress homes.
Liability for general purpose computing is not going to happen. It would make software way more expensive...
Issues of liability vs cost are determined by different factors, people, and institutions. There are a lot of variables in play. There is not one entity who decides, "Perhaps software should assume greater liability for security, but, nah, then it would be too expensive."
Security liability is determined by people suing and winning money for damages caused by insecure software. This will increase costs which will hurt free software, and small developers. For the competent few, this will be a bad thing. For everyone else that has to deal with the crap put out both by large and small groups of developers, this will be a good thing in the long run.
Now ELUAs essentially say, "we are not responsible for damage, data loss, financial loss, or other bad things that happen to you or our customers when you use our buggy, insecure, and poorly designed product that doesn't actually do all we said it does." This is ridiculous, but the uneducated consumer is not putting enough market pressure on the software industry to force better practices. In the long run, this hurts the industry because there is not enough disincentive for the incompetent to get out of the way. Thus, we have to put up with too many sloppy coders, unrealistic schedules, clueless managers, and poor design concepts.
Yes, adding the possibility of being sued for insecure software will make it more expensive. Yes, it will make it harder for freeware, adware, and small developers to compete. Yes, in a minority of cases, this is a loss, but as the majority of inferior developers and their products will be unable to afford the liability of law suits, it will open up more opportunities for the responsible and capable.
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.
This is true, but mainly because the public is not willing to pay for the value offered. We want our software to be amazing, we want it now, and we don't really want to pay for it. Then we complain when corners are cut (security is just one area). This is not a sustainable model.
The public will pay more if they must. The value of many products far exceed the costs. Financial pressures of security liability would force the production of more secure products. This will drive up the price, but the public will pay for it if the product is truly useful. Those incompetent developers that cannot compete because they cannot create secure enough products will fail, giving more room for the competent to flourish.
... 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.
If I drop a plugged in, turned on, toaster into a bathtub with someone in it, I am held liable if they die, not the toaster manufacturer. This is because the toaster came with a warning not to do such a thing. If this same toaster (before the terrible bathtub incident) catches on fire and burns my house down while toasting bread, then I can sue the manufacturer. In this case, I am using the toaster for its intended purpose when the mishap occurred.
To say that the software developer cannot know or cannot define how the software will be used is shirking responsibility to customers and the general public. Right now, the software industry is getting away with it. The public will not indefinitely allow us this failure to take responsibility for the products we develop. Those seemingly silly, common sense warnings that come with the toaster are the result of lawsuits and regulations because the public used the toaster in other ways than was intended. People suffered then sued. This means that toasters cost more money. On the plus side, we have (generally) working toasters that do what they are supposed to do without shorting out our electrical circuits or burning our houses down. There will always be exceptions.
Countries that do not have liable laws that protect their citizens and/or whose government does not adequately regulate or enforce safety tend to produce inferior and dangerous products. This is one reason people in some places will pay more for several American products--they tend to be more reliable and safer because our legal system and government force US manufacturers to meet higher standards. This is not what is happening in the software industry. Countries that force higher standards on software used within that country will attract developers who are able to meet the demands of that market. That superior product will eventually be in demand elsewhere.
There is a lot of insecure, crappy software out there that threatens to do much worse than burn individual houses down. Software developers will have to conceive of how their software will be used; they will have to define those uses; and they will need to clearly communicate those uses to the end users in easy to understand language. Eventually, the public will require these things through lawsuits and government regulation. In the long run, it will be good for the software industry and capable developers.
I disagree !!!