Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

If or When? Expand / Collapse
Author
Message
Posted Thursday, April 10, 2014 11:34 AM
SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Wednesday, August 27, 2014 12:03 PM
Points: 621, Visits: 2,127
OCTom (4/10/2014)
Hackers are not going to try to hack all severs. They look for the easiest or most rewarding path.


fixed in bold.

You can be really hard to get into, but if there is a strong incentive to hit you for either direct gain or the notoriety gained based on your name, not being easy isn't good enough.

Post #1560560
Posted Thursday, April 10, 2014 11:28 PM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Monday, August 25, 2014 4:31 PM
Points: 215, Visits: 843
I'm pro-"when".

The reasoning is that if you propose security to the business as an "if" case, the answer is always, "no, that will never happen, because we're not a target - we don't have any enemies". Management doesn't understand that it's not a personal issue, that hackers can run automated attacks against anonymous targets, and desire either information or resources.

Meanwhile, the IT approach is "if we firewall it, then there's no hope". Except things end up not being firewalled. Or the firewall goes down. Or the firewall gets hacked. Or whatever port is opened for the firewall gets hacked. Or someone VPNs in. Or a third party integrated data source is hacked.

So, forget "if". Make it "when". What did we have in place to show that we did what we could to detect the intrusion quickly and minimize what could be siphoned out (with development, duh!) What do our contracts / policies entitle our clients to? Where's our backups if things get serious? What are we going to do?

Of course. Few ever do. Though Australia just released new privacy policy legislation so that companies who didn't make any effort to secure their data are going to be in BIG trouble. Of course, it's going to take a few to go down in flames before the rest start investing in fixing all of the past hacks they've done to get around doing things properly.

Post #1560707
Posted Friday, April 11, 2014 2:17 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Today @ 1:08 AM
Points: 67, Visits: 427
In my humble opinion you should always prefer "when' over "if", that should be true for security as much as for recovery. With recovery the "when" scenario makes you practice bare metal restores to be prepared "when" disaster strikes, even "if" the changes are quite small that it will happen to you any time in the near future. In fact, you may be making backup copies of every data asset for years without a single occasion where you could not proceed without them.

The same approach might become common for security breaches. You should take measures to minimize the risk, but also prepare for the event and set up proper procedures to act upon a breach. But the big difference with recovery is that it is not just a technical issue. For recovery you only need to convince the management that you need the resources (time being one of them) to be prepared, and the rest can be handled completely by the technical staff preferably without any interference of those non-technical-schooled managers. If you give us enough hardware, software and time, we'll ensure that everything can be recovered when disaster strikes. At least to a certain extend ...

Security breaches require much broader attention. After putting a plug in the hole, you need to asses the risks of further attacks from hackers using the information they have collected about your technical infrastructure, like accounts and maybe even passwords. You might stumble upon a sieve instead of a single hole, and need additional measures to secure your data from a technical point of view. But there are so many other aspects involved, from communicating the effects to your customers up to changing the policies on access from mobile devices, or even hiring a specialist or ethical hacker to investigate how secure your data is actually.

We can olny inform our managers of the threats and risks and of the available countermeasures, but unlike recovery getting the resources to do something about it is not enough. There are no 'set and forget' solutions, but every one should know what to do "when" a data breach has occured and all of a sudden valuable data has become public property. Never say "if" when it comes to security, just like you should never say "if" with recovery measures. Just hope (and pray) that all your preparations turn out to be superfluous for a very long time.
Post #1560754
Posted Friday, April 11, 2014 3:45 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Friday, August 22, 2014 9:29 AM
Points: 34, Visits: 162
There are many circumstances in life where we prepare for relatively unlikely events. We install sprinklers and fire extinguishers in buildings,
air bags in cars, pilots train for engine failures and forced landings and many other emergencies. We back up our computer systems.

When these things happen, it is better that we have thought about how we respond to them, and put facilities in place to mitigate the consequences.

I am sure many of us have participated in Disaster Recovery exercises. Sorry, it is called Business Continuity these days. Data breaches are just
one of the scenarios you cater for in BC planning.
Post #1560783
Posted Friday, April 11, 2014 3:57 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Yesterday @ 6:32 PM
Points: 5,356, Visits: 3,054
john.riley-1111039 (4/11/2014)
There are many circumstances in life where we prepare for relatively unlikely events. We install sprinklers and fire extinguishers in buildings,
air bags in cars, pilots train for engine failures and forced landings and many other emergencies. We back up our computer systems.

When these things happen, it is better that we have thought about how we respond to them, and put facilities in place to mitigate the consequences.

I am sure many of us have participated in Disaster Recovery exercises. Sorry, it is called Business Continuity these days. Data breaches are just
one of the scenarios you cater for in BC planning.


I suppose just like the security procedures air stewards and stewardesses go through with each flight. They never do it because they believe that there is a risk for that particular flight but because in the unlikely situation that there is a problem then everyone is best prepared.


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1560789
Posted Friday, April 11, 2014 7:37 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 1:50 PM
Points: 1,652, Visits: 4,713
Gary Varga (4/11/2014)
john.riley-1111039 (4/11/2014)
There are many circumstances in life where we prepare for relatively unlikely events. We install sprinklers and fire extinguishers in buildings,
air bags in cars, pilots train for engine failures and forced landings and many other emergencies. We back up our computer systems.

When these things happen, it is better that we have thought about how we respond to them, and put facilities in place to mitigate the consequences.

I am sure many of us have participated in Disaster Recovery exercises. Sorry, it is called Business Continuity these days. Data breaches are just
one of the scenarios you cater for in BC planning.


I suppose just like the security procedures air stewards and stewardesses go through with each flight. They never do it because they believe that there is a risk for that particular flight but because in the unlikely situation that there is a problem then everyone is best prepared.

Even if we think (we can't know) that there is only a very slim chance that the organization's data will become the target of a hacker, another reason for having security best practices in place is to demonstrate due dilligence. In the aftermath of an attack, there is going to be a lot of finger pointing, both within the organization and from external sources like the media, class action lawyers, and law enforcement.
Post #1560913
Posted Friday, April 11, 2014 8:53 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 12:57 PM
Points: 33,206, Visits: 15,361
Eric M Russell (4/10/2014)

The standards would not have to be very technical. Dedicated sysadmin accounts, removal of service accounts from sysadmin role, seperation duties, application accounts with minimal privilege (ie: no ad-hoc sql and access only to required tables), encryption at rest for columns containing sensitive data, encrypted backups, encrypted connections between application and database layer: these basic best practices would apply to any enterprise database platform. If a database platform doesn't provide support, then the organization has simply chosen the wrong platform.


Sounds good in practice, but this is somewhat how PCI and SOX are written. The problems come in when the encryption is poor, i.e. using MD5 for passwords, or someone argues about what minimal privilege is.

I do think the government should lay out some framework and then industries, perhaps with groups like SANS, should give more guidance and detail on what would constitute good security for a platform and version.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1560984
Posted Friday, April 11, 2014 9:05 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 1:50 PM
Points: 1,652, Visits: 4,713
Steve Jones - SSC Editor (4/11/2014)
Eric M Russell (4/10/2014)

The standards would not have to be very technical. Dedicated sysadmin accounts, removal of service accounts from sysadmin role, seperation duties, application accounts with minimal privilege (ie: no ad-hoc sql and access only to required tables), encryption at rest for columns containing sensitive data, encrypted backups, encrypted connections between application and database layer: these basic best practices would apply to any enterprise database platform. If a database platform doesn't provide support, then the organization has simply chosen the wrong platform.


Sounds good in practice, but this is somewhat how PCI and SOX are written. The problems come in when the encryption is poor, i.e. using MD5 for passwords, or someone argues about what minimal privilege is.

I do think the government should lay out some framework and then industries, perhaps with groups like SANS, should give more guidance and detail on what would constitute good security for a platform and version.

Obviously the government, wether it be Congress or some agency dedicated to the task, can't come up with the standards; it has to be the industry putting their heads together, sort of like the various standards working groups for HTML or network protocols.
We can argue about what minimal privilege is, for example does the DBA also need to be local Admin on the server, or does the Network Admin or service accounts also need to be sysadmin on the database server.
However, when it comes to discussions about wether the developer, CEO, or director of business analytics needs to be SYSADMIN on the database server, then that's not even worth discussing; the answer is obviously no. We all have to move past that.
Post #1560996
Posted Friday, April 11, 2014 9:11 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 12:57 PM
Points: 33,206, Visits: 15,361
Eric M Russell (4/11/2014)

Obviously the government, whether it be Congress or some agency dedicated to the task, can't come up with the standards; it has to be the industry putting their heads together, sort of like the various standards working groups for HTML or network protocols.
We can argue about what minimal privilege is, for example does the DBA also need to be local Admin on the server, or does the Network Admin or service accounts also need to be sysadmin on the database server.
However, when it comes to discussions about whether the developer, CEO, or director of business analytics needs to be SYSADMIN on the database server, then that's not even worth discussing; the answer is obviously no. We all have to move past that.


In some sense, yes, but what about SSC? For years I was the CTO and one of the developers, as well as the DBA? It's not clear cut in terms of how you do this.

The rules should be, if you don't administer the box, you aren't an administrator. However that can vary dramatically, especially in small companies. You always need a backup. You also need to remember that the way privileges work on different platforms (*Nix, OSX, etc.) can be different, so it's not as simple as specifying roles or groups.

I'm not saying you aren't correct here in terms of what you'd like to accomplish, but that it's very complex to figure out how to apply this broadly. The one thing I'd note is that for all applications, they should be able to run at less than admin privileges. However even that's hard. What about apps that gather telemetry or metrics from the box? Often that requires some level of admin access. What about adding accounts?

It's overall, a mess.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1561006
Posted Friday, April 11, 2014 9:40 AM


SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Yesterday @ 1:50 PM
Points: 1,652, Visits: 4,713
Steve Jones - SSC Editor (4/11/2014)
Eric M Russell (4/11/2014)

Obviously the government, whether it be Congress or some agency dedicated to the task, can't come up with the standards; it has to be the industry putting their heads together, sort of like the various standards working groups for HTML or network protocols.
We can argue about what minimal privilege is, for example does the DBA also need to be local Admin on the server, or does the Network Admin or service accounts also need to be sysadmin on the database server.
However, when it comes to discussions about whether the developer, CEO, or director of business analytics needs to be SYSADMIN on the database server, then that's not even worth discussing; the answer is obviously no. We all have to move past that.


In some sense, yes, but what about SSC? For years I was the CTO and one of the developers, as well as the DBA? It's not clear cut in terms of how you do this.

The rules should be, if you don't administer the box, you aren't an administrator. However that can vary dramatically, especially in small companies. You always need a backup. You also need to remember that the way privileges work on different platforms (*Nix, OSX, etc.) can be different, so it's not as simple as specifying roles or groups.

I'm not saying you aren't correct here in terms of what you'd like to accomplish, but that it's very complex to figure out how to apply this broadly. The one thing I'd note is that for all applications, they should be able to run at less than admin privileges. However even that's hard. What about apps that gather telemetry or metrics from the box? Often that requires some level of admin access. What about adding accounts?

It's overall, a mess.


Granting database access to domain groups, rather than user accounts, can prevent the need for network admins to touch the database server for routine situations like when a new employee is hired.

For situations where a 3rd party monitoring tool or individual needs access to things like system views, execution plans, or traces, the following permissions can be used. They don't need sysadmin or even db_datareader membership.

In my current role, I'm not the DBA on the production servers, but I'm often the go to guy for troubleshooting performance issues or situations where something broke in production and they need to know what's going on ASAP.

The following grants me everything I need to get the job done without handing over the keys to the city. I'm relying on profiler tracing less often and don't usually request that unless I know up front it's required. This can also be implemented by the DBA as a role with accounts added or removed only as needed.

-- server level permissions require that context be changed to [master] database.
use master
-- grant user permission to view execution plans:
grant showplan to [account|role];
-- grant user permission to view object schemas:
grant view any definition to [account|role];
-- grant user permission to view system tables and views:
grant view server state to [account|role];
-- grant user permission to start sql profiler traces:
grant alter trace to [account|role];

Post #1561023
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse