|
It really depends on the problem; everyone on that list can be blamed for something, depending on the situation.
It can even be the user if he didn't follow the installation security instructions/requisites.
|
|
|
|
|
AlexCode wrote: It really depends on the problem; everyone on that list can be blamed for something, depending on the situation. You can blame me if I do something wrong, but would not be responsible for any damages. Unless there is criminal intent, the employee is safe (as should be).
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
I agree that there's a thin line here.
Although the developer cannot be held responsible for the client damage, the blame can cascade down if the employer sues him. So you won't be on trial for the client's damages but for the damages you caused to your employer.
Usually, this goes along with the developer simply being fired but it would really depend on how responsible the developer is and how much damage he caused.
I'm not a lawyer, obviously, but I don't see this as an impossible scenario.
|
|
|
|
|
AlexCode wrote: Although the developer cannot be held responsible for the client damage, the blame can cascade down if the employer sues him The employer would only be able to sue if the employee is not "doing as told" or does not have the qualifications he/she claimed to have.
It's also something that isn't unique to our sector. Ask your doctor
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Everyone has a stake in security. I checked everything.
"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music."
-- Marcus Brigstocke, British Comedian
|
|
|
|
|
Good One!!
I liked this answer.
Life is a computer program and everyone is the programmer of his own life.
|
|
|
|
|
Erik Burd wrote: I checked everything.
Including "None of the above"
|
|
|
|
|
Me too.
Sorry for my bad English
|
|
|
|
|
|
because it is a chain, where the weakest part determinates its strengths.
What about a super-secure system, where the password is "0000000"
Or the super-duper password is the browser cache or is on a post-it.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
Balmer was foreseeing this very question!
Quote: A hardcoded password, a SQL injection, a system with a known issue, or not changing the default password.
Hardcoded password: Developer. No one else can have responsibility for this.
SQL injection: Developer. We know the risks, or we shouldn't be doing the job. There's even cartoons explaining how to do SQL Injection, but some morons keep right on concatenating strings to form SQL commands. Nobody else is to blame here.
System with a known issue: Partly developers. I don't let stuff out without fixing the problems or making damn sure everyone knows the problem is there. And neither should you ... because it will be blamed on you when it bites someone, so all you can do is say "I told you all" to cover your ass.
Not changing the default password: This isn't all us: but we should "expire" default passwords immediately to make sure they are changed. We can help with this one... Good old admin/password | CommitStrip[^]
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Agree
For those saying... CEO, User, whatever else... that will be only true if you have written evidence that you explained it and they refused to hear you and decided to continue without the recommended security.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
As a developer, it is very hard if impossible to convict the one above you that security is necessary... and if they don't even gave you the time to build an application without considering security issues, then what do you thing will be the first thing left?
Obviously, a good programmer should understand what is SQL injection and how to avoid it...
In my experience, it is very hard to explain such necessity to someone who thing that no one would ever try to hack your system or application... And even, if you would be able, then they would not have time, resource or budget for that!
Philippe Mori
|
|
|
|
|
Philippe Mori wrote: In my experience, it is very hard to explain such necessity to someone who thing that no one would ever try to hack your system or application...
Second link in this message[^] should do the job. One of the best explanations for non techies I have read
Then add... using that, they can get enough information to steal you or just directly delete everything and destroy your client-portfolio. They will "really? I didn't thought..."
"You can lose a lot of money" is the best argument
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
I disagree 100%.
In the real world, it usually doesn't fall on the developer. If you are self employed then you are sh*t out of luck, especially if you don't have a strong grasp on security.
And, by the way, SQL injection is the least of your troubles when dealing with security.
Most companies that I have worked for, have a security officer/department that takes full responsibility for this sort of stuff.
My code has to pass a security audit before it is deployed. Does yours?
|
|
|
|
|
Until something is hacked, you don't have to worry about it
Hogan
|
|
|
|
|
I think that many small company think like that...
And also think that if a problem occurs, it could be fixed in no time and without much consequence while in reality the code was mostly not written with security in mind often from people that does not know how a system can be hacked... Thus if such problem occurs, the might not have any idea of what to do.
Philippe Mori
|
|
|
|
|
For example, if you develop a web site for a client, then that client has to specify that he wants a secure web site.
Obviously, if the site allows to make financial transactions or keep informations that are really confidential (like credit card numbers), those who are responsible for the development should take appropriate actions.
For anything in between, it should be specified in the contract if the user want a given level of security and obviously the cost of building the system should be adjusted to implement and validate desired security level.
Obviously, a programmer should follows good programming practices like using parametrized SQL queries, storing hash for passwords and using secure RTL functions to reduce the possibility of systems being compromise by taking advantage of that.
Philippe Mori
|
|
|
|
|
I have a friend who studied accounting, he ordered an online shop to a company.
When I asked him about if the web was SQL-Injection secured, he was like
Let me translate your comments to another discipline:
if you are ill and need medical attention, you need to tell the doctor, which organ of your body must be healed or which medicament do you agree to take. And that, without knowing which kind of illness you have.
Obviously if you have an accident and you are bleeding, the doctor should close your cuts and try to stop your bleeding.
For everything in between, you need to specify it in the contract if you want to get 100% healed or if you want them to cement your broken leg.
Obviously a doctor that treats patients should follow good practices, like washing his hands, using sterile tools to recude the possibility of an infection.
Would you think the same if you were that patient?
I see the "money" factor and what is on the contract and all this argumental line, but at least is your responsability to explain what are the options, the risks, the costs and possible alternatives. Then, and I repeat then what you say can be accepted. You can't push the responability about something to someone who has no idea and is paying you for your work.
If you explain everything to the customer, and he still wants do things in a particular way... then it starts being his fault. Before that point... it is entirely responsability of the developer.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
modified 24-Oct-16 11:32am.
|
|
|
|
|
Well, from what I have seen is that is the customer does not specifically ask for things like HTTPS, not much would be done for security...
In fact, I have seen system security be somewhat decreased by making the "lost password procedure" more user friendly.
I have also heard a lot of answers of the type "the user does not care or does not need to know or that peoples are honest..."
Philippe Mori
|
|
|
|
|
... because that's who may be held accountable for security breaches or their consequences. Pointing at anyone else will not work if something like this ends in a courtroom.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
When it comes to security, the developers do what the security officer says, not what the developer says.
If you have a good security officer (and team if you are so lucky), then you should have a robust system, security wise.
It has been my experience that most developers don't really know anything about security, even if they think they do, they really don't.
modified 24-Oct-16 8:17am.
|
|
|
|
|
"There can be lots of fingerprints on that knife"
Sounds like a good blamestorming session. In my experience it's best to pick someone who's out sick or on holidays, that way they aren't there to defend themselves.
|
|
|
|
|
The best are those who resigned, as they won't be back with a vengeance.
DURA LEX, SED LEX
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
The bigger the c**k-up, the higher the blame should travel:
The developer should get it in the neck for being incompetent.
The testing team should be carpeted for not spotting the developer's ineptitude.
The PM should be hung out to dry for not keeping an eye on the ball.
The HR team should be slammed for having hired the aforementioned failures.
The CEO should fall on his sword because he's clearly running a ship of fools.
The buck has to stop somewhere.
|
|
|
|