August 7, 2015 at 2:59 pm
I don't know enough about the Cyberark product to save my own life if it became necessary.
That notwithstanding, these types of products supposedly eliminate the need for any administrator logins on the server either by group or individually except for its own login. That's why it uses a single login... only the app has privs to do anything. Think of such an app as SSMS on steroids with all the security/change logging that you wish SQL Server had. That's what such products are and auditors love 'em.
Because no one can actually get to the server without the app, everything has to be done through the app. The app would be the only login with "SA" privs. DBAs would "tell" the app what they want to do in a relatively transparent fashion. The app would check credentials and either do what the DBA asked or deny it. Most such apps will allow you to do things that a sysadmin priv would do but the app can be controlled to not allow a DBA to create sysadmin prived logins (for example) but could do just about anything else. It all goes through and depends on the app. DBAs wouldn't be able to log directly into the server. They'd log into the app and the app would log into the server.
So the idea of a "single login" for all DBAs isn't actually what it seems. The app will keep track of everything based on the individual AD logins that the DBA has.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 7, 2015 at 4:12 pm
mister.magoo (8/7/2015)
Sqlbill, how do they restrict the network people that can grant access to the account/group so that they don't work in cahoots with the villain?
We have a legal document (security and legal put it together) with a list of the approved people who can be assigned access. The email to the server admins must include the email from the approving authority that is granting the access. So we can't just say, add this DBA to the access so they can do this work. That's why we let the business group know the process of actually getting the work done would be greatly increased.
Plus we have auditing in place that records who is accessing the database and it is reported to security and legal.
-SQLBill
August 7, 2015 at 4:51 pm
I'd still suggest they add each of your DBAs, use a group for access, and disable all accounts. Then when an issue arises, they can activate only the account needed.
August 8, 2015 at 10:11 am
Jeff Moden (8/7/2015)
I don't know enough about the Cyberark product to save my own life if it became necessary.That notwithstanding, these types of products supposedly eliminate the need for any administrator logins on the server either by group or individually except for its own login. That's why it uses a single login... only the app has privs to do anything. Think of such an app as SSMS on steroids with all the security/change logging that you wish SQL Server had. That's what such products are and auditors love 'em.
Because no one can actually get to the server without the app, everything has to be done through the app. The app would be the only login with "SA" privs. DBAs would "tell" the app what they want to do in a relatively transparent fashion. The app would check credentials and either do what the DBA asked or deny it. Most such apps will allow you to do things that a sysadmin priv would do but the app can be controlled to not allow a DBA to create sysadmin prived logins (for example) but could do just about anything else. It all goes through and depends on the app. DBAs wouldn't be able to log directly into the server. They'd log into the app and the app would log into the server.
So the idea of a "single login" for all DBAs isn't actually what it seems. The app will keep track of everything based on the individual AD logins that the DBA has.
It does initially sound attractive or at least interesting on paper. That said - it could easily go the other way as well: what protects CyberArk (or other quivalent)? Once the hackers eventually crack it - then they don't just have SA access to a specific server, they have all access to all assets, everywhere. And no one with privileged access to combat the issue. This is one of those shiny objects that scare me: anything encouraging you to throw all security eggs in one basket has always been a mistake in my experience (which from my high level of expertise from a 30 sec read of the site seems to be the case).
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
August 8, 2015 at 10:40 am
Matt Miller (#4) (8/8/2015)
Jeff Moden (8/7/2015)
I don't know enough about the Cyberark product to save my own life if it became necessary.That notwithstanding, these types of products supposedly eliminate the need for any administrator logins on the server either by group or individually except for its own login. That's why it uses a single login... only the app has privs to do anything. Think of such an app as SSMS on steroids with all the security/change logging that you wish SQL Server had. That's what such products are and auditors love 'em.
Because no one can actually get to the server without the app, everything has to be done through the app. The app would be the only login with "SA" privs. DBAs would "tell" the app what they want to do in a relatively transparent fashion. The app would check credentials and either do what the DBA asked or deny it. Most such apps will allow you to do things that a sysadmin priv would do but the app can be controlled to not allow a DBA to create sysadmin prived logins (for example) but could do just about anything else. It all goes through and depends on the app. DBAs wouldn't be able to log directly into the server. They'd log into the app and the app would log into the server.
So the idea of a "single login" for all DBAs isn't actually what it seems. The app will keep track of everything based on the individual AD logins that the DBA has.
It does initially sound attractive or at least interesting on paper. That said - it could easily go the other way as well: what protects CyberArk (or other quivalent)? Once the hackers eventually crack it - then they don't just have SA access to a specific server, they have all access to all assets, everywhere. And no one with privileged access to combat the issue. This is one of those shiny objects that scare me: anything encouraging you to throw all security eggs in one basket has always been a mistake in my experience (which from my high level of expertise from a 30 sec read of the site seems to be the case).
So very true. Something like CyberArk is absolutely wonderful for making auditors and soccer Moms happy but it always boils down to the root problem and no software in the world can overcome it. If you look at all of the recent major hacks, most of them were caused by careless in-house people or contractors that exposed their own high-prived logins. People forget that hackers aren't going to try to break in as one of the minions of a company. They're going to try to break in as one of the known DBAs or other high prived users that do have sysadmin privs. Once in, it's all over except for the press release and the crying.
I'm one of those that believes that you can audit all you want but nothing will ever correctly replace well trained, trustworthy DBAs or other trustworthy Admins.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 8, 2015 at 11:15 am
Jeff Moden (8/8/2015)
I'm one of those that believes that you can audit all you want but nothing will ever correctly replace well trained, trustworthy DBAs or other trustworthy Admins.
Jeff, I couldn't agree with you more. Having trustworthy people who know what they're doing are the key things for any administrator, SQL or network.
August 8, 2015 at 2:16 pm
Jeff Moden (8/8/2015)
Something like CyberArk is absolutely wonderful for making auditors and soccer Moms happy but it always boils down to the root problem and no software in the world can overcome it. ...I'm one of those that believes that you can audit all you want but nothing will ever correctly replace well trained, trustworthy DBAs or other trustworthy Admins.
Or soccer dads 😉
Quote of the day imho.
Shiny object just to please some auditor etc.
Good security is a layered approach and starts with trustworthy people.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
August 9, 2015 at 7:58 am
SQLRNNR (8/8/2015)
Jeff Moden (8/8/2015)
Something like CyberArk is absolutely wonderful for making auditors and soccer Moms happy but it always boils down to the root problem and no software in the world can overcome it. ...I'm one of those that believes that you can audit all you want but nothing will ever correctly replace well trained, trustworthy DBAs or other trustworthy Admins.
Or soccer dads 😉
Quote of the day imho.
Shiny object just to please some auditor etc.
Good security is a layered approach and starts with trustworthy people.
Designing something with enough security where trustworthy professionals can do their jobs without undue restraints should be the goal. Auditing is reactive, and should be relied upon to troubleshoot for improvements. And can be rendered useless if any items can be deleted.
All Admins need to be trustworthy, whether DBA or any System or Network Admin. They also need to be well trained.
Layered goes into separation of duties, so changes are implemented through the actions of several people, who also do some review of what they are implementing, not just blindly put in the changes.
Also some of this can vary by size of the company and what is at risk.
Trustworthy gets back into when someone stumbles across an exploit, do they keep it to themselves? Or work with others to close the gap?
You want the white hat hackers on your side. For example, I had a consultant come back one time to work on security on our ERP System. I mentioned a shop floor ID even could get back to the system source code. He learned something new that day - can't be done can be an assumption. I also was instructed by part of the ERP system to do an update to some data, they were too busy to get to it and felt I could handle it. End result was I did the update, then worked with the system Admin to secure it, as I found a hole where many of the users could have granted themselves access to do the same. This was after the system was 'secure'.
So Security is also an ongoing project, what is secure today might only be a hole someone has not found yet.
August 9, 2015 at 10:04 am
Greg Edwards-268690 (8/9/2015)
SQLRNNR (8/8/2015)
Jeff Moden (8/8/2015)
Something like CyberArk is absolutely wonderful for making auditors and soccer Moms happy but it always boils down to the root problem and no software in the world can overcome it. ...I'm one of those that believes that you can audit all you want but nothing will ever correctly replace well trained, trustworthy DBAs or other trustworthy Admins.
Or soccer dads 😉
Quote of the day imho.
Shiny object just to please some auditor etc.
Good security is a layered approach and starts with trustworthy people.
Designing something with enough security where trustworthy professionals can do their jobs without undue restraints should be the goal. Auditing is reactive, and should be relied upon to troubleshoot for improvements. And can be rendered useless if any items can be deleted.
All Admins need to be trustworthy, whether DBA or any System or Network Admin. They also need to be well trained.
Layered goes into separation of duties, so changes are implemented through the actions of several people, who also do some review of what they are implementing, not just blindly put in the changes.
Also some of this can vary by size of the company and what is at risk.
Trustworthy gets back into when someone stumbles across an exploit, do they keep it to themselves? Or work with others to close the gap?
You want the white hat hackers on your side. For example, I had a consultant come back one time to work on security on our ERP System. I mentioned a shop floor ID even could get back to the system source code. He learned something new that day - can't be done can be an assumption. I also was instructed by part of the ERP system to do an update to some data, they were too busy to get to it and felt I could handle it. End result was I did the update, then worked with the system Admin to secure it, as I found a hole where many of the users could have granted themselves access to do the same. This was after the system was 'secure'.
So Security is also an ongoing project, what is secure today might only be a hole someone has not found yet.
Exactly. Good examples, too, Greg.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 10, 2015 at 4:46 am
mister.magoo (8/7/2015)
Sqlbill, how do they restrict the network people that can grant access to the account/group so that they don't work in cahoots with the villain?
Or worse, so they can't grant access to themselves.
August 10, 2015 at 1:06 pm
I think the design of many of these auditing products is to log and detect issues, not prevent them. Nor should they be under the control of the privileged users whose efforts are being logged.
Certainly there are flaws in them and hackers could take advantage of issues, but most of the hackers are aiming for a goal of getting a valid account and copying information, not necessarily searching for audit records and altering them. Some have done this in the past with central *nix logs, and the Windows event log/SQL log, but many that are using scripts or tools, aren't looking further than they need to.
August 11, 2015 at 4:54 am
Steve Jones - SSC Editor (8/10/2015)
I think the design of many of these auditing products is to log and detect issues, not prevent them. Nor should they be under the control of the privileged users whose efforts are being logged.Certainly there are flaws in them and hackers could take advantage of issues, but most of the hackers are aiming for a goal of getting a valid account and copying information, not necessarily searching for audit records and altering them. Some have done this in the past with central *nix logs, and the Windows event log/SQL log, but many that are using scripts or tools, aren't looking further than they need to.
Do these programs retain passwords for the user accounts they are auditing? If not, then they aren't the hacker's gold mine some of us assume they are. But still, if they have the ability to grant permissions, one might assume, they also have the ability to add users.
August 11, 2015 at 7:43 am
Steve Jones - SSC Editor (8/10/2015)
I think the design of many of these auditing products is to log and detect issues, not prevent them. Nor should they be under the control of the privileged users whose efforts are being logged.Certainly there are flaws in them and hackers could take advantage of issues, but most of the hackers are aiming for a goal of getting a valid account and copying information, not necessarily searching for audit records and altering them. Some have done this in the past with central *nix logs, and the Windows event log/SQL log, but many that are using scripts or tools, aren't looking further than they need to.
Despicable types that are inhouse might like to cover their tracks by altering logs. External hackers might also try if they got in with good enough control to do so and they found a gold mine in the data and want to return undetected so they can continue to mine.
I'm with you, though. I wouldn't balk at a logging system that, as a DBA, I couldn't get to provided that it wasn't causing performance or resource issues.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 11, 2015 at 8:15 am
Brandie Tarvin (8/11/2015)
Steve Jones - SSC Editor (8/10/2015)
I think the design of many of these auditing products is to log and detect issues, not prevent them. Nor should they be under the control of the privileged users whose efforts are being logged.Certainly there are flaws in them and hackers could take advantage of issues, but most of the hackers are aiming for a goal of getting a valid account and copying information, not necessarily searching for audit records and altering them. Some have done this in the past with central *nix logs, and the Windows event log/SQL log, but many that are using scripts or tools, aren't looking further than they need to.
Do these programs retain passwords for the user accounts they are auditing? If not, then they aren't the hacker's gold mine some of us assume they are. But still, if they have the ability to grant permissions, one might assume, they also have the ability to add users.
These applications don't hold the passwords, etc... but they don't have to. This is more in line with the concept of application roles: you log in with a "normal account" and within the context of the app, it escalates your privileges to enable you to perform whatever functions are required. If the DBA or system admins were to bypass the application, they would not have access (or perhaps only public access) to the DB server.
Just like in the past where several exploits didn't go after breaking passwords, they just hijacked an authentication token (man in the middle attacks), cracking your way into something like this CyberArk would allow you to grant anyone you wished admin access on any asset in the corporation.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
August 11, 2015 at 1:01 pm
Brandie Tarvin (8/11/2015)
Steve Jones - SSC Editor (8/10/2015)
I think the design of many of these auditing products is to log and detect issues, not prevent them. Nor should they be under the control of the privileged users whose efforts are being logged.Certainly there are flaws in them and hackers could take advantage of issues, but most of the hackers are aiming for a goal of getting a valid account and copying information, not necessarily searching for audit records and altering them. Some have done this in the past with central *nix logs, and the Windows event log/SQL log, but many that are using scripts or tools, aren't looking further than they need to.
Do these programs retain passwords for the user accounts they are auditing? If not, then they aren't the hacker's gold mine some of us assume they are. But still, if they have the ability to grant permissions, one might assume, they also have the ability to add users.
The ones I've seen do not.
Viewing 15 posts - 16 through 30 (of 35 total)
You must be logged in to reply to this topic. Login to reply