December 22, 2015 at 1:18 am
Ivanova (12/21/2015)
Slightly off-topic; while working for a large financial institution, I was approached by one of the security team. He was a highly-paid and allegedly very security-savvy contractor. His request (although phrased more as a demand) was for me to give sysadmin rights on most of our production instances to the penetration testers coming on-site as part of his project.It's fair to say that he was disappointed, and also that he didn't handle disappointment particularly well.
He can't be security-savvy if he was to bypass security for a penetration test. That is the exact opposite of what is needed at that point!
You'll be within your rights to have him removed from site for trying to circumvent security for unknown reasons (bit extreme maybe).
December 22, 2015 at 1:22 am
Adrian Chapman (12/22/2015)
Ivanova (12/21/2015)
Slightly off-topic; while working for a large financial institution, I was approached by one of the security team. He was a highly-paid and allegedly very security-savvy contractor. His request (although phrased more as a demand) was for me to give sysadmin rights on most of our production instances to the penetration testers coming on-site as part of his project.It's fair to say that he was disappointed, and also that he didn't handle disappointment particularly well.
He can't be security-savvy if he was to bypass security for a penetration test. That is the exact opposite of what is needed at that point!
Maybe the request was part of the penetration test.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
December 22, 2015 at 2:26 am
The request was allegedly so that the pen testers could check how the instances had been configured.
I told the security 'expert' that his pen testers could submit their diagnostic scripts to our DBAs for review and they could sit with the DBAs while they ran the scripts (if approved) and gathered the results. He had to be content with that.
I would dearly have loved to see the guy removed from the site; far from that happening, he won the next 'employee of the month' award, at which point I lost any ambition I might have had to try for the same award. It just goes to prove that some know very well how to blind management with bs.
Anyway, the main thing was, the other DBAs and I managed to protect the databases from this guy, and we were very content with that.
December 22, 2015 at 5:43 am
Eric M Russell (12/21/2015)
Ed Wagner (12/21/2015)
Eric M Russell (12/21/2015)
I think the whole concept of a 'SA' account is a bad idea, because essentially it's an account which has full access and which can be sharable across users. It becomes a back door for lazy developers, "Black Ops";-) deployments, and hackers.Hey, it gives something to disable. It also gives us something to monitor to make sure it stays disabled. 😉
Yes, whenever the special "SA" account trips an audit alert; it would be kind of fun to creep up behind them and say "Whatcha Doin?".
I so, so, so like this idea...
But, we've got checks in place that look for an SA account, and if it finds one, well...
"Lucy, you got some 'splainin to do!"
Even if it were for something like this, I don't think auditors here would appreciate the humor...
December 22, 2015 at 6:08 am
jasona.work (12/22/2015)
Eric M Russell (12/21/2015)
Ed Wagner (12/21/2015)
Eric M Russell (12/21/2015)
I think the whole concept of a 'SA' account is a bad idea, because essentially it's an account which has full access and which can be sharable across users. It becomes a back door for lazy developers, "Black Ops";-) deployments, and hackers.Hey, it gives something to disable. It also gives us something to monitor to make sure it stays disabled. 😉
Yes, whenever the special "SA" account trips an audit alert; it would be kind of fun to creep up behind them and say "Whatcha Doin?".
I so, so, so like this idea...
But, we've got checks in place that look for an SA account, and if it finds one, well...
"Lucy, you got some 'splainin to do!"
Even if it were for something like this, I don't think auditors here would appreciate the humor...
I started out with it being an item I audit in my quarterly audit. I eventually created a job that that runs frequently and checks the status of the login and sends me a text if it's enabled. The near real-time monitoring is the "trust but verify" approach. There are only two of us who can enable it, so it hasn't happened yet.
December 22, 2015 at 6:54 am
Ivanova (12/21/2015)
Slightly off-topic; while working for a large financial institution, I was approached by one of the security team. He was a highly-paid and allegedly very security-savvy contractor. His request (although phrased more as a demand) was for me to give sysadmin rights on most of our production instances to the penetration testers coming on-site as part of his project.It's fair to say that he was disappointed, and also that he didn't handle disappointment particularly well.
Congratulations, you past the trickiest part of the test. He should have at least taken you out to lunch afterward.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 22, 2015 at 10:09 am
Cody K (12/21/2015)
andrew gothard (12/21/2015)In fact, using a highly privileged single account for app access is nothing more than deliberate incompetence.
The last time I heard something like this said the person saying it was fired. Your job as a DBA doesn't extend to making demands about how vendors build their applications, nor making value judgements about their staff.
I'm really glad we don't tolerate this kind of vicious attitude towards colleagues and vendors in our workplace 🙂
The fact that neither of us would tell a vendor this directly to their face in this manner does not mean it isn't true. And as I have been known to tell vendors, the simple fact of the matter is if my employer is paying them, they absolutely do have the right to call the tune over shoddy security which can harm their reputation and the interests of those they owe a duty of care.
If someone engaging in shoddy and unprofessional practices releases your bank details or health records to the wide world, will you judge them kindly if it was a third party app, "and they can't tell a vendor how to secure their app before putting my data in it"?
I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.
December 23, 2015 at 6:37 am
I think somebody said "disable SA" earlier in this thread. But best practice is ( was? ) to assign job ownership to SA. Another recent article here on SS.com advocated not using sql logins at all. I objected based on my particular situation where people are added or removed from AD groups without my knowledge, but another reason is that we have processes operating across domains ( e.g. California to Ohio ) and AD authentications depends on finely tuned "forests."
December 23, 2015 at 7:07 am
Indianrock (12/23/2015)I think somebody said "disable SA" earlier in this thread. But best practice is ( was? ) to assign job ownership to SA.
Jobs which are assigned to a SQL login continue to function even after the logins are disabled.
December 23, 2015 at 7:43 am
That's possibly rather unpleasant. I'll have to check that.
I can see it's use, but it's also rather dangerous...
December 23, 2015 at 7:48 am
n.ryan (12/23/2015)
That's possibly rather unpleasant. I'll have to check that.I can see it's use, but it's also rather dangerous...
I would argue that having the sa account is one of the most dangerous situations you can create.
December 23, 2015 at 7:54 am
How is SA ( with good password properly managed and not used by applications ) any worse than your own "admin" sysadmin login?
December 23, 2015 at 8:30 am
Eric M Russell (12/21/2015)
I think the whole concept of a 'SA' account is a bad idea, because essentially it's an account which has full access and which can be sharable across users. It becomes a back door for lazy developers, "Black Ops";-) deployments, and hackers.
I agree. No OS/platform needs a God account. There probably need to be 3-4 separate functional accounts for different things, but since we didn't design this from the early outset, it hasn't been re-built in there.
December 23, 2015 at 8:44 am
Indianrock (12/23/2015)
How is SA ( with good password properly managed and not used by applications ) any worse than your own "admin" sysadmin login?
Because it can be shared across multiple users.
We know who MYCORP\JoeBlack is, and we know who members of MYCORP\DBAProduction are. We take Joe out the SYSADMIN role or we can add or drop members from the MYCORP\DBAProduction domain group as needed. However, we don't know for sure who has the credentials for the 'SA' account, and when the password changes, we don't know what applications, linked servers, or services need to be updated in tandem with the new 'SA' password, so it's a maintenance nightmare.
Also, developers have this tendency to check check SSIS packages and .config files into source control with the credentials for the 'SA' account in plain text. In an organizations where applications and ETL packages login using 'SA', if you have access to the source control system (which is everyone in IT), then you know how to login to the database server as SYSADMIN. You know you're not supposed to, but if you're determined to do it anyway, the credentials for the 'SA' account are right there.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
December 23, 2015 at 9:28 am
If you can add groups or members to groups ( or your systems people do it quickly when asked and always communicate when changes are made ),
then AD only sounds good.
Hasn't been the case here. For production I use individual AD logins with custom permissions for the relative few with prod access.
I'll have to test if a disabled SA account can actually own and run sql agent jobs. If so I don't see why SA couldn't be disabled. But I would think if you're going down that road there shouldn't be any sysadmin logins that look like "admin" , "JSmithAdmin" or anything of the sort.
If you need to make a DAC connection I presume an AD login works. For our cross-domain authentication, we do have some sql logins due to "trust" issues.
Viewing 15 posts - 61 through 75 (of 95 total)
You must be logged in to reply to this topic. Login to reply