Live data from Hacker News

So sue me: are lawyers really the key to computer security?

arstechnica.com

21–24 of 24 posts

Re: So sue me: are lawyers really the key to computer security?

#21
post #5

Rather than drag the lawyers into this, (just more paperwork)why don't we look at it from the perspective of the tools we are using? For SQL injection, what stops databases from building an input scrubber that sits between the database and user input and scrubs input to block SQL injection? Or for that matter, why don't we see languages and frameworks used for web development touting the fact they include robust secu…

Nothing stops them from doing that. But they don't. Now what? See, we're back at the premise of the article.

It's been a while coming, but this isn't surprising. Years ago, Nancy Leveson predicted that failures in software systems would lead to quality improvements through lawsuits and legislation, similar to what happened in the early 19th century with steam boilers; http://sunnyday.mit.edu/steam.pdf

It's just a matter of enough of the right people being pissed off, and software is going to find itself more subject to contract laws (click through EULAs won't cut it) and liability.

Re: So sue me: are lawyers really the key to computer security?

#22
post #14
post #12

I have always believed that it will ultimately be the insurers (through liability insurance conditions) who enforce server security, rather than courts and lawyers. I don't see this as a bad thing.

You should. If insurance is going to solve this, wait 15 years and we'll all need certifications to commit code.

Something is definitely going to change.If it's not insurance driven, then it will be legislated for some types of code.

In most states you need a license just to cut hair. Software can easily cause more damage than a hairdresser.

Re: So sue me: are lawyers really the key to computer security?

#23
post #19

I hold an unpopular opinion that lawyers and lawsuits are a great way to motivate companies to "do the right thing", where in this case the "right thing" we're talking about is protecting customer data. Another great motivator for doing the right thing is knowing that customers will vote with their wallets. Unfortunately this isn't always a strong enough motivation because some markets don't have enough competition,…

It's going to work for about a year, then when there is a security failure the company will turn around run git/svn blame and sue the individual employee. Hopefully the laws would be written so that when you post security best practices in your TOS and the customer does not follow them the liability can be mitigated (eg. don't reuse passwords on multiple sites) Re: AT&T where are they going to go? T-Mobile?

It's going to work for about a year, then when there is a security failure the company will turn around run git/svn blame and sue the individual employee.

You bring up an interesting topic which is an extension of the first one. If the forces motivating a company to do the right thing are 1) desire to gain and not lose customers 2) desire to not be penalized by the government and 3) desire to not be sued, then what motivates an employee to also do the right thing? (I'm generalizing the question because this applies to so many things, but I'll switch back to talking about "building secure software" as a specific example of "doing the right thing".)

A software developer should be motivated to build secure code because of these motivators: 1) Desire to build or maintain a good reputation among peers 2) Desire to not get fired 3) Desire to protect employer from harm 4) Desire to protect customers from harm 5) Desire to just do things the right way for the sake of preferring good things over bad. (There's probably a more elegant way to phrase that last one, but it's like how an architect might fight against proposed changes to a blueprint for the sake of the building itself.)

To err is human, and companies are composed of humans. When a company hires a software developer, they are inherently taking on the risk that this human will make mistakes, so I don't think developers should be legally liable for bugs or vulnerabilities in their code unless they are incredibly egregious or intentional. It's the company's responsibility to anticipate the possibility of bugs and vulnerabilities, and to mitigate that risk by hiring good people, and by having good policies, procedures and training. (By having code reviews and conducting security audits, for example.)

I'm sure we're in agreement that developers shouldn't be sued for mistakes in their code, but whether or not they can be sued for honest mistakes is another question. I don't know what the law has to say about that, but if employees aren't already protected against lawsuits for non-egregious mistakes then that should be changed.

Hopefully the laws would be written so that when you post security best practices in your TOS and the customer does not follow them the liability can be mitigated (eg. don't reuse passwords on multiple sites)

I totally agree.  Customers have to bear some of the responsibility as well.

Re: AT&T where are they going to go? T-Mobile?

My point exactly! Going back to three motivators I mentioned for companies to do the right thing, AT&T knew it wouldn't lose a significant number of customers over the NSA spying issue because there's not much competition in their space. (That and apathy, unfortunately.) Also, they knew they wouldn't get penalized by the government for, well, forking data over to the government. That leaves the only viable option being to sue AT&T... except that power was taken away by retroactively granting AT&T immunity by FISA. ( http://en.wikipedia.org/wiki/Hepting_v._AT%26T ) This is what makes the AT&T/NSA issue so upsetting. All motivations for AT&T and other telecoms to "do the right thing" have been taken off the table.

Re: So sue me: are lawyers really the key to computer security?

#24

Rather than drag the lawyers into this, (just more paperwork)why don't we look at it from the perspective of the tools we are using? For SQL injection, what stops databases from building an input scrubber that sits between the database and user input and scrubs input to block SQL injection? Or for that matter, why don't we see languages and frameworks used for web development touting the fact they include robust secu…

I think you just described PHP's old magic quotes feature, which automatically escaped all user input to, among other things, block SQL injection. It's universally reviled as one of PHP's worst design decisions and is no longer part of the default feature set.

Because it escaped input too early (and did not fully escape), not because auto escaping sql is a bad idea.
Post reply on HN