December 23, 2015 at 9:30 pm
Comments posted to this topic are about the item Correct Old Mistakes
December 24, 2015 at 5:38 am
It's what is known as Technical Debt isn't it? Rightly or wrongly (and I would suggest wrongly) it usually comes down to a question of money, i.e. how much is it going to cost to fix these as yet undiscovered and unexploited problems rather than thinking about the costs (legal, reputationally and others) of being hacked.
Seasons greetings to all in the SQL Server community.
Lempster
December 24, 2015 at 6:55 am
My kids had (and still use occasionally today) a VTech Leapster handheld game console. However, we never registered it; they simply play the games. It's not neccessary for comanies to request the name, dob, address, etc. for folks who use their products. At most all they need is an email address for measureing their user base and occasional promotions and tech support.
Despite being a database profressional, I'll admit I'm a critic and skeptic when it comes to Big Data, Internet Of Things, and Social Media. I keep seeing the lay public and even fellow IT profressionals doing dumb sh!t with sensitive data that should never have been collected in the first place.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 24, 2015 at 7:45 am
It would be fascinating to hear from the developers in stories like this (at least anonymously).
Was it due to pressure, or was it due to a lack of experience/knowledge? I've seen entire IT departments that have lacked skills in certain areas, simply because no-one has those skills, they're not that important to the day-to-day work, and so they're not hiring people for those skills.
For myself, I know 2 jobs ago I had a whole host of blind spots in my knowledge that I don't have today, thanks to working at different companies and seeing different ways of doing things. And while I'm sure I still have blind spots today, I can imagine companies that hire primarily entry-level workers, or where their employees tend to be long-lasting (neither of which are bad things by themselves) would have bigger blind-spots than companies with more turnover, or that have the funds to attract experienced staff.
Leonard
Madison, WI
December 24, 2015 at 7:54 am
phonetictalk (12/24/2015)
It would be fascinating to hear from the developers in stories like this (at least anonymously).Was it due to pressure, or was it due to a lack of experience/knowledge? I've seen entire IT departments that have lacked skills in certain areas, simply because no-one has those skills, they're not that important to the day-to-day work, and so they're not hiring people for those skills.
For myself, I know 2 jobs ago I had a whole host of blind spots in my knowledge that I don't have today, thanks to working at different companies and seeing different ways of doing things. And while I'm sure I still have blind spots today, I can imagine companies that hire primarily entry-level workers, or where their employees tend to be long-lasting (neither of which are bad things by themselves) would have bigger blind-spots than companies with more turnover, or that have the funds to attract experienced staff.
Often times developers are compartmentalized regarding what aspects of the application they work on, so they can't "see the forest for the trees" in terms of security issues in the overall architecture. It would be sort of like asking a low ranking soldier years afterward why the battle was lost, but all he can really recall was manning his station or hunkering down in a trench waiting for orders.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 24, 2015 at 8:14 am
Lempster (12/24/2015)
It's what is known as Technical Debt isn't it? Rightly or wrongly (and I would suggest wrongly) it usually comes down to a question of money, i.e. how much is it going to cost to fix these as yet undiscovered and unexploited problems rather than thinking about the costs (legal, reputationally and others) of being hacked.Seasons greetings to all in the SQL Server community.
Lempster
Some is technical debt, which usually around how hard things are to maintain. Some is just mistakes (bugs) or poor / ancient coding that needs updating.
It does some down to money, but some effort should be made to regular fix or update code. At least I'd hope so.
December 24, 2015 at 8:15 am
phonetictalk (12/24/2015)
Was it due to pressure, or was it due to a lack of experience/knowledge? I've seen entire IT departments that have lacked skills in certain areas, simply because no-one has those skills, they're not that important to the day-to-day work, and so they're not hiring people for those skills.
Great points, and I agree. We often do have these blind spots, though many people don't address them over time. To be fair, it's hard to do so if you don't realize you have a blind spot.
December 24, 2015 at 9:41 am
Ok, as a developer I'm gonna reveal a dirty little secret that NO ONE wants to admit.
Yes, there are best practices in security. Every developer knows (or should know!) better than to store passwords in the clear for example.
But common-sense best practices won't cut it. 99.999% of developers are rank security amateurs (myself included). We can encrypt a password and store it given a function.
However: the average developer is an unarmored foot soldier on a battlefield dominated by enemy Bolos.
You heard me. The life-expectancy of code written by 99.999% of developers has that small a chance of surviving a determined attacker. Rifles against nukes and hellbores--I know who I'd bet on...
Security is a SPECIALTY. Secure *coding* is trivial compared to the real security issues, which are architect-level. Which algorythms are used in the encryption? How are keys to encryption stored? Are trusted certificates REALLY secure? Can we trust the encryption standard du jour? (SHA-1, SHA-256, Triple DES, ad naseum). What happens when one of these core pieces are compromised?
And once we build this uber-secure environment (which is time and money intensive) how many *MINUTES* will it be before some bright-spark douche-bag breaks in and steals the crown jewels?
I say minutes, not as an exaggeration, but as a historically probable unit of measurement.
Given the NSA has already slipped in compromised algorythms in the past, given that *somebody* snuck code into Juniper firewalls that's been undiscovered for *years* just what chance is there that YOUR uber-castle of a website will weather the tsunami of spiteful attacks headed its way?
VTech was particularly pathetic, yes. But I guarantee a lot of it was management poo-pooing the idea they needed a group of security specialists to handle the design and assist in the implementation and maintenance of "just a website, you idiots! Who's gonna wanna hack us anyway?????".
Yeah.
December 24, 2015 at 1:22 pm
Excellent! We are in the middle of a Brownfield analysis. This message is exactly what my management needs to hear right now. We are updating a 2005 application with 3DES security which is now passé. Thanks for putting this message out there.
December 27, 2015 at 7:53 am
It's scary to think back at how much bad code I've written over the years, trying to be efficient, ignoring security entirely. Hopefully my code has been rewritten and improved.
January 19, 2016 at 10:27 am
Lack of knowledge.
Lack of experience.
Lack of direction.
Lack of time.
Lack of imperative.
There is often nothing driving the security needs. No stakeholder caring usually means no one will commit to it.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 11 posts - 1 through 10 (of 10 total)
You must be logged in to reply to this topic. Login to reply