May 17, 2011 at 10:44 pm
Comments posted to this topic are about the item Stalking the Bad Guys
May 18, 2011 at 5:06 am
If you made an uncontrolled change to a system in the way you describe, that is really no better than the person who put the suspected malicious code in.
Better to ask around and see if anyone claims ownership - there may be a legitimate reason for it.
If no-one does, then you can raise a change to remove it, and trial it on your test system if you have one.
Good code will always say who wrote it, when, and what it does. And good management includes protecting your systems from unauthorised changes.
And another thing. There aren't that many bad guys. They are outnumbered many to one by people who make honest mistakes due to incomplete understanding. Hands up anyone who has NEVER done that?
May 18, 2011 at 7:46 am
It should be considered a good practice for a DBA to setup a notification or report of what objects are created or updated on the production server. That way one doesn't just stumble upon a strange object without having a clue about where it came from or for long it's been in place. Correlating the objects creation date with past deployment schedules can help associate it with a legitimate process.
If you trace usage of the suspicious procedure back to a legitimate login account, perhaps a 3rd party performance monitoring tool, then you can restrict the permissions on the account to only what they claim is needed. For example, if it needs to collect and log statistics into a table, then it doesn't need to be a member of SYSADMIN or even have read access on your application tables. Instead, just start with a minimal public account and then grant it ALTER TRACE and VIEW SERVER STATE permission along with INSERT permission on it's logging table.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 18, 2011 at 8:55 am
I've set up notifications, not just for objects, but also sp_configure changes and agent jobs, just to try and catch any "undocumented" changes.
May 18, 2011 at 9:10 am
Once you said honeypot, it all came together for me. I think that having honeypots on a network are a good idea. I like the idea also of tracing the code and documenting when and how it is being called. Let the necessary people know and then proceed from there.
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
May 18, 2011 at 10:59 am
Part of this is going to be balancing the risk between turning off functionality that you're not familiar with and how much damage can happen if you don't. There will be cases where what's being done clearly isn't legit so the risk that you're breaking something is far less than the risk of letting whatever it is continue. I would imagine that would be the minority of the cases like this though. I would also imagine that you would want to contact the application owner for the server very quickly to find out if it's legit so it's important to know who that person or group is.
May 18, 2011 at 11:40 am
Steve usually does such a good job of covering the more business side of things that I'm kind of surprised neither he nor anyone else mentioned: to me, step one, before taking any other action, is to get your company's counsel and / or security team involved - at least let them know something (very suspicious) happened. If you don't do this first, you are taking a very big risk; these people, in particular, need to be out front of any surprises of this nature......
-f
May 18, 2011 at 6:05 pm
Yes, my first thought when I read this was how close is it to entrappment.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply