November 11, 2013 at 12:24 pm
Gary Varga (11/11/2013)
Dave, not trying to start an argument. It sounded as though you were saying that there is no point starting now as it is already too late but I now think you may have meant that there is no point after a breach has been committed. I guess it may be too late after a breach has been committed but a resolution still should be attempted.Steve, sorry but I disagree. Yes, examples should be complete including best security practices where appropriate, however, it does have an impact on effort. Security needs planning, design and testing. Also it may need infrastructure as well as investment in hardware and/or software. Then there is maintenance, management and training. And after all that I still believe it is a sound investment.
I do not read what you wrote as trying to start an argument. No worries at all.
I think I am the one who is having difficulty describing my point. Let me do it another way. If we take an example where a company has not done anything to date, and so they begin today to figure out what needs to be done. Next week they start fixing things. They know it will take 6 months to do so. If in 1 month they get hacked, and the result of the hacking is that they end up closing their doors permanently, then my point is it was too late.
That does not mean we shouldn't try. On the contrary, I am trying to convey the point that even starting now may be too late, but of course we can hope it isn't too late. I fear in some cases, we are so far past where we need to be, that some companies simply can't afford what it is going to take to fix things.
I did not intend to convey an opinion that it is too late to start. I also do not mean to convey that it is too late after a breach has occurred, odds are everyone has had a breach anyhow. i am simply trying to convey that regardless of when we start, in hindsight we may find it was too late, that we should have started earlier.
Now, if this isn't clear enough, I am going to just give up. I know what I want to say, but me thinks I am failing!
Next, you expressed exactly what I was going to attempt to say in regards to Steve's comment, but I gave up as I did not want to sound critical of his points. I agree with Steve that we should try, just that there are costs whether we see them or not. You said it better than I was going to.
Dave
November 11, 2013 at 4:15 pm
djackson 22568 (11/11/2013)
I think I am the one who is having difficulty describing my point. Let me do it another way. If we take an example where a company has not done anything to date, and so they begin today to figure out what needs to be done. Next week they start fixing things. They know it will take 6 months to do so. If in 1 month they get hacked, and the result of the hacking is that they end up closing their doors permanently, then my point is it was too late.
That does not mean we shouldn't try. On the contrary, I am trying to convey the point that even starting now may be too late, but of course we can hope it isn't too late. I fear in some cases, we are so far past where we need to be, that some companies simply can't afford what it is going to take to fix things.
I did not intend to convey an opinion that it is too late to start. I also do not mean to convey that it is too late after a breach has occurred, odds are everyone has had a breach anyhow. i am simply trying to convey that regardless of when we start, in hindsight we may find it was too late, that we should have started earlier.
Now, if this isn't clear enough, I am going to just give up. I know what I want to say, but me thinks I am failing!
Next, you expressed exactly what I was going to attempt to say in regards to Steve's comment, but I gave up as I did not want to sound critical of his points. I agree with Steve that we should try, just that there are costs whether we see them or not. You said it better than I was going to.
Pretty clear, and makes sense to me. It will be too late for some, not for others. Ultimately you never know until you close your doors.
In terms of costs, for some it's minor, some it's easily doable over time, some it's not cost effective at all.
November 11, 2013 at 4:22 pm
Steve Jones - SSC Editor (11/11/2013)
I'd still argue this is more an internal developer professionalism issue more than a business case.We, as people that teach and help others, need to present good examples and teach people with some level of best practices at all levels. Not dumbing down examples with "blank passwords", no error handling, code that allows SQL Injection, etc.
If people have the skills and knowledge, it becomes less of an issue because it doesn't really take longer to write the code well at the start.
In terms of refactoring, no idea how to present the case that things need to change. Adobe is a good example, though many business people might prefer to roll the dice that their information will not be lost/copied.
I think this is the perfect justification for the implemenation of standards and 100% code reviews. It also justifies special test software that will test the begeesus out of your applications for "penetration". We do both.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 11, 2013 at 4:52 pm
Jeff Moden (11/11/2013)
Steve Jones - SSC Editor (11/11/2013)
I'd still argue this is more an internal developer professionalism issue more than a business case.We, as people that teach and help others, need to present good examples and teach people with some level of best practices at all levels. Not dumbing down examples with "blank passwords", no error handling, code that allows SQL Injection, etc.
If people have the skills and knowledge, it becomes less of an issue because it doesn't really take longer to write the code well at the start.
In terms of refactoring, no idea how to present the case that things need to change. Adobe is a good example, though many business people might prefer to roll the dice that their information will not be lost/copied.
I think this is the perfect justification for the implemenation of standards and 100% code reviews. It also justifies special test software that will test the begeesus out of your applications for "penetration". We do both.
Jeff, it would seem you are fortunate to work for someone who understands the real world. I am happy for you! I only wish the attitude your company has was more prevalent. Sadly, both businesses and countries seem to frequently ignore it.
Dave
November 12, 2013 at 2:44 am
Steve Jones - SSC Editor (11/11/2013)
Gary Varga (11/11/2013)
Steve, sorry but I disagree. Yes, examples should be complete including best security practices where appropriate, however, it does have an impact on effort. Security needs planning, design and testing. Also it may need infrastructure as well as investment in hardware and/or software. Then there is maintenance, management and training. And after all that I still believe it is a sound investment.Yes, but password management, authentication, secure coding for sql calls, all of these techniques and skills exist. If we all used them from the beginning, as part of our habit, the effort in planning and engagement would be much, much lower.
I'm not saying all security decisions can be removed, but lots can.
In the context of SQL Server, yes. And I guess as this is SQLServerCentral.com then that is default context but it often exists in the overall stack of an application and we must remember that it can be more complex and therefore costly (not just monetarily).
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
November 12, 2013 at 2:50 am
djackson 22568 (11/11/2013)
Jeff Moden (11/11/2013)
Steve Jones - SSC Editor (11/11/2013)
I'd still argue this is more an internal developer professionalism issue more than a business case.We, as people that teach and help others, need to present good examples and teach people with some level of best practices at all levels. Not dumbing down examples with "blank passwords", no error handling, code that allows SQL Injection, etc.
If people have the skills and knowledge, it becomes less of an issue because it doesn't really take longer to write the code well at the start.
In terms of refactoring, no idea how to present the case that things need to change. Adobe is a good example, though many business people might prefer to roll the dice that their information will not be lost/copied.
I think this is the perfect justification for the implemenation of standards and 100% code reviews. It also justifies special test software that will test the begeesus out of your applications for "penetration". We do both.
Jeff, it would seem you are fortunate to work for someone who understands the real world. I am happy for you! I only wish the attitude your company has was more prevalent. Sadly, both businesses and countries seem to frequently ignore it.
I agree with Jeff.
Unfortunately, from my experience I also agree with Dave.
The only solution I have been able to come up with is to push for best practices everywhere I go. I'd rather try and fall short then fail to do what I perceive as my professional duty.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply