January 12, 2017 at 12:17 am
Comments posted to this topic are about the item Backup Data Security
January 12, 2017 at 4:43 am
I have raised system security questions only to be told to assume that it was covered, when everyone knew that it wasn't, as it was outside of my area. Not the smartest of moves in my opinion.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 12, 2017 at 6:24 am
Gary Varga - Thursday, January 12, 2017 4:43 AMI have raised system security questions only to be told to assume that it was covered, when everyone knew that it wasn't, as it was outside of my area. Not the smartest of moves in my opinion.
I've been in a similar situation once before. The application being developed contained the sort of information you really want to keep secure and every suggestion I made towards ensuring that security was pooh-poohed or (and I admit this now) not reasonable for the budget / price point of the application.
January 12, 2017 at 7:12 am
I think all IT folk should have a decent security course and exam as a mandatory requirement for companies providing their own IT capability. And there should be refresher courses every 2 years. Security is going to get every more important and I think we are going to hear some absolute horror stories this year.
The security guys asked a lot of questions
Who controls the storage, the hardware, the network?
Who controls the starters/leavers process?
What are the lines of responsibility for each system?
Who can build hardware?
How are the systems separated from each other?
What can be accessed over the internet?
If systems can be accessed over the internet is there a bastion through which those systems are accessed i.e you can access the bastion, the bastion can access a data system in a tightly defined way but you cannot go around the bastion.
Is data encrypted at rest?
Is data encrypted in transit?
Are backups encrypted?
Who controls the encryption keys?
Are the keys kept in a secure location?
Do you monitor hardware creation?
Do you deactivate logins if they have not been used within a tight time window?
What penetration testing is done and how frequent?
What constraints do you put on penetration testing i.e. what is descoped and why?
What ports and protocols are used?
What network subnets can talk to other network subnets?
How strong are the encryption keys?
The list went on and on. The eye opener was that for quite a few questions the answer was "Don't know".
January 12, 2017 at 7:36 am
Firewalls are an essential first defense, but it's still kind of like the plate glass windows at the bank; a determined intruder can eventually find a way in.
Even if your organization uses an encrypted backup solution, that doesn't prevent a privileged user from simply performing a one-off unprotected backup, copying the data files to another location, or walking out the door with the hardware. I'm currently working on a project to implement TDE on all of our on-prem and Azure hosted database servers. Once TDE is enabled on a database, it can't be restored or attached without first re-creating the certificate on the target server.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 12, 2017 at 9:24 am
The problem is, nobody pays developers to do security, and developers aren't held accountable for the security flaws in their systems. Of course, it's hard to hold someone accountable for doing something they're not trained to do. My team wants to be more security-savvy, but there are some pretty substantial barriers to making the organization's professional development policy work for us, and in a lot of cases we don't even know what we don't know.
I think we should be hiring security people, just like we hire DBAs and IT people to do different jobs, and part of the security person's job should be to make sure everyone in the organization knows basic best practices for keeping things secure. Then organizations could start having policies that enforce security practices instead of just paying for lawyers to fight for them when something goes wrong.
January 12, 2017 at 10:44 am
Security has to be baked into the infrastructure and development process rather than sprinkled on top of a deliverable like spice. For example, servers and databases in development should be provisioned by the DBA with default security in place, and developer should not have privilege to alter security settings or add logins without a change request. If the application and database objects are developed within those constraints, then the developers will soon learn what's "normal", how to code within the box, and the deliverable will deploy to production without issue.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 12, 2017 at 11:09 am
Just a quick note for Steve:
Couldn't send messageCouldn't send message. Possible reasons"
- The recipients disabled private messaging.
- A recipient's inbox is full.
Return to previous page.
and a note that the legal protections for this data are critical as well.
412-977-3526 call/text
January 12, 2017 at 12:44 pm
The problem with security is it must be *perfect*, against every possible attack every single time. The attacker only have to be lucky *once*.
Given this, no matter how insane the security, somebody will figure out how to break it. The more complex the system the *easier* it is to break.
Given those constraints, the best you can do is slow down an attacker. Oh, and limit the data you don't need to store. If it isn't there they can't steal it. 🙂
January 12, 2017 at 2:20 pm
Eric M Russell - Thursday, January 12, 2017 10:44 AMSecurity has to be baked into the infrastructure and development process rather than sprinkled on top of a deliverable like spice. For example, servers and databases in development should be provisioned by the DBA with default security in place, and developer should not have privilege to alter security settings or add logins without a change request. If the application and database objects are developed within those constraints, then the developers will soon learn what's "normal", how to code within the box, and the deliverable will deploy to production without issue.
Great statement "Security has to be baked into the infrastructure and development process rather than sprinkled on top of a deliverable like spice. "
January 12, 2017 at 11:36 pm
Gary Varga - Thursday, January 12, 2017 4:43 AMI have raised system security questions only to be told to assume that it was covered, when everyone knew that it wasn't, as it was outside of my area. Not the smartest of moves in my opinion.
Agreed.
My strategy at several companies has been to form an alliance very early on with the security team (educating them if necessary on what can go wrong in the database arena) and then invite them into the fray. While development managers may think is feasible to tell a 'mere' DBA to pull their head in, they are more careful around security analysts.
Most of the developers I've met have been keen to do a good job, it's been management which has been more willing to cut corners, and the antidote to that has to come from further up the company hierarchy. The presence of a security team is an indication that the company at least pays lip-service to the notion. Its absence may be an indication that it's time to look for another job.
January 13, 2017 at 8:20 am
hammackk - Thursday, January 12, 2017 9:24 AMThe problem is, nobody pays developers to do security, and developers aren't held accountable for the security flaws in their systems.
I often myself feel like I am trying to do a very good job, but often seen as someone of an odd person. To give one example, I recently was asked to install SQL-Server and create a new database. Correct me if I am wrong, but I read a lot about the SA account and that it should not be used and disabled, so I did and created admin accounts instead. When passing the database to a 3-rd party the first thing they did was to recreate a new instance and use the SA account to setup another database because they had some sort of trouble cofiguring their part.
A few years ago when I joined my company one of my suggestions was to stop using FTP/Telnet, RCP, Etc. I started installing and using SSH, mainly it was our parent company that requested this to be used. Just today I finished installing SSH on another old outdated AIX server, thankfully I still had the old software packages. Nobody else from my admins are ever bothered that "rcp" is still in use.
I find some third party companies the bigest culprits. They develop their software, sell it, that's what only counts. They use default settings, SA accounts and you have to give PUBLIC and DB_OWNER privileges for users for the application to be able to perform it's functions. Usually after 3-6 months when a database is handed over to a DBA it turns out it doesn't even have a backup.
January 13, 2017 at 8:30 am
Eric M Russell - Thursday, January 12, 2017 10:44 AMSecurity has to be baked into the infrastructure and development process rather than sprinkled on top of a deliverable like spice.
I would agree, however there is one problem. Your management may be outsourcing a lot of applications and whatever process control you have in place cannot be used or usually is ignored by managment. Any reasonable suggestions from local admins can be ignored and are often dismissed are scaremongering. Adminstrators should be part of the implementation process right from the beginning when the opposite is the case. A DBA is the last person to be informed a new database has just been setup and is up and running. Too late to implement any serious security measures.
January 13, 2017 at 8:32 am
Steve Jones - SSC Editor - Thursday, January 12, 2017 12:17 AMComments posted to this topic are about the item Backup Data Security
Where I work now I think they do a better job at security. I give them kudos.
The one thing I've been meaning to talk to our chief security officer about is what are the practices they want developers to follow, to harden the software we write. This article reminds me to follow through on that.
Kindest Regards, Rod Connect with me on LinkedIn.
January 13, 2017 at 9:22 am
Too bad they couldn't just come out with the systems fully secured so that you couldn't set them up unsecured. If we should encrypt then don't allow a system be set up that wasn't. That sort of thing. I mean if an unsecured setup is bad, why allow it to exist that way. Don't allow that kind of setup.
Viewing 15 posts - 1 through 15 (of 25 total)
You must be logged in to reply to this topic. Login to reply