October 3, 2015 at 11:25 am
Comments posted to this topic are about the item What Can You Do?
October 3, 2015 at 7:28 pm
I use to work at a smaller scale here, but I told my boss on previous projects that I'm responsible for the security and well being of our data and systems. I do everything I can to educate myself and eradicate vulnerabilities when they are found.
If there is push back on securing that data. I will normally double check with my boss on whether or not if he is okies with losing just some of the data, not all of the data to a breach. That normally sets the tone and we make the magic happen. Pushback on security should never be an option if holes are found.
October 3, 2015 at 8:28 pm
So many of these breaches just make me angry because they could have been and should have been prevented. A prefect case of this was Home Depot. The quote "We sell hammers" will be forever ingrained in my brain as the ultimate denial of reality. I understand that developers everywhere are under tremendous pressure to get things done on time and under budget, but I don't think it should ever come at the expense of security. If an 8-hour job takes an extra 2 hours to do correctly, then that's just the cost of doing business. The same thing applies to a 200-hour change. I know my management does not want to hear about the company on the news. There's always a new attack being developed, but many of them can be prevented by design. I don't expect this to hold true forever, but what is preventable should be prevented.
I don't think I'll ever get used to hearing about data breaches and quite honestly, I hope I don't get used to it. I also hope it doesn't devolve into the blame game. In the T-Mobile case, it's being reported as an Experian problem. If Experian was hacked and only T-Mobile customers were impacted, what vulnerability is there and why haven't others been impacted...yet? If the hole is there, it needs to be closed.
October 5, 2015 at 2:00 am
There seems to be a collective state of denial around security. "It will never happen to us"!
The reality is that companies are playing Russian Roulette. The resources available to malicious parties increase every year. It's a case of increasing bullets, decreasing chambers and itchy trigger fingers. Not a good combination
October 5, 2015 at 8:15 am
From what I've seen, few data breaches are the result of exploiting holes in the database engine itself. The major RDMS are solid in terms of security; and SQL Server itself is probably the best from that perspective. The biggest problem for database administrators is that they don't have a solid server configuration, network infrastructure, or application developers covering their bases.
Installing SQL Server on Windows Core Edition can help, because it reduces the surface area for attack and prevents IT staff from doing risky stuff like installing 3rd party apps or web browsing on the server.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 5, 2015 at 8:22 am
Eric M Russell (10/5/2015)
From what I've seen, few data breaches are the result of exploiting holes in the database engine itself. The major RDMS are solid in terms of security; and SQL Server itself is probably the best from that perspective. The biggest problem for database administrators is that they don't have a solid server configuration, network infrastructure, or application developers covering their bases.Installing SQL Server on Windows Core Edition can help, because it reduces the surface area for attack and prevents IT staff from doing risky stuff like installing 3rd party apps or web browsing on the server.
If there needs to be an IPsec policy set up do you really want the average dba doing it or you windows administrator?
I would say the application architecture is the biggest issue. Have an application that has crud access to all tables then there is minimal amount of security that can be applied. Have an application that does needless access and the updates then any auditing becomes quickly unmanageable.
October 5, 2015 at 8:50 am
October 5, 2015 at 9:07 am
GoofyGuy (10/5/2015)
... there have been no shortage of cases where management or technical staff avoided securing their systems.
And now for a different opinion[/url].
Sometimes developers are being asked to perform their jobs with both hands tied behind the back.
Security guys are great, DBAs as blockers now pale into insignificance!
They are running into the same challenges and same battles that DBAs faced. From what I can see they can at least argue that their stuff is backed by legal and compliance regulations.
There is a need for some pragmatism. There comes a point where the security architecture becomes so complicated that it becomes less secure.
I've seen a situation where no one internally could review the log files that revealed that an internal system was being accessed externally. Time to diagnosis was too long ditto time to fix
October 5, 2015 at 9:17 am
David Poole wrote:
There is a need for some pragmatism.
Indeed. We need to find a balance. I'm by no means arguing we should open our kimonos to the world, just that we need to work together to find a happy medium between security and design/development.
Thanks for a thoughtful response.
October 14, 2015 at 12:28 pm
GoofyGuy (10/5/2015)
David Poole wrote:There is a need for some pragmatism.
Indeed. We need to find a balance. I'm by no means arguing we should open our kimonos to the world, just that we need to work together to find a happy medium between security and design/development.
Thanks for a thoughtful response.
The trouble as I've experienced it is that a lot of developers and a lot of their managers are interested neither in a pragmatic approach nor in finding a happy medium, just in getting code out of the door as fast as possible. Or maybe they think the happy medium is paying only lip service to security, or addressing only some of the security issues and not others (eg we'll have a decent firewall so that everything will be secure but out website will connect to SQL server as SA and construct commands using strings provided by the end users). That sort of thing seems to be far more common than the other way - making such a complex mess with far more security than is appropriate and rendering the system poisonously difficult to use, although that does happen too.
Tom
October 14, 2015 at 12:39 pm
The trouble as I've experienced it is that a lot of developers and a lot of their managers are interested neither in a pragmatic approach nor in finding a happy medium, just in getting code out of the door as fast as possible.
Worked for Microsoft, did you?
October 15, 2015 at 4:08 pm
GoofyGuy (10/14/2015)
The trouble as I've experienced it is that a lot of developers and a lot of their managers are interested neither in a pragmatic approach nor in finding a happy medium, just in getting code out of the door as fast as possible.
Worked for Microsoft, did you?
No. If they'd set up their Cambridge Lab a year earlier than they did I might have tried to go and work there, but when they did open it I'd moved into a new job the previous year and wasn't interested in another switch of employer right then. I don't think they were particularly bad, plenty of other companies pushed out much worse rubbish that they did. They've survived, so enough of their customers must have found what they built worth paying for to enable them to do so, and that is more that most companies in the software business managed to do.
Tom
November 11, 2015 at 12:46 am
Here in the UK TalkTalk (a telecomms company) recently had a breach due to SQL Injection. It turns out that numerous IT managers (from IT Director down) had left in the six months leading to the breach.
I wonder if they were fighting for appropriate funding or resource allocation and gave up after failing once again. It is just speculation but if they were likely to be held accountable then I can imagine them leaving of their own accord in order to wash their hands of it...that or they got a better offer.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 13 posts - 1 through 12 (of 12 total)
You must be logged in to reply to this topic. Login to reply