December 13, 2021 at 8:45 pm
Hold on. I explicitly stated that auditors should not be able to change anything on the system. Talking about giving auditors "sysadmin" is a straw man.
Scripts that capture full permissions across hundreds of dbs (in our instances) can be very complex. I don't have time -- nor the inclination, frankly -- to review all their code. I do review their conclusions to make sure they are accurate.
We just completed an audit. I answered some qs but I did not run any of the code. Then again, they didn't have authority to change anything on the system, just to query it. I don't understand why anyone would feel they need to review code that just reads metadata during an audit. Is that just me?! I don't think so.
in order to do a full permissions you do need higher privs - without alter login you can't view logins, to see database permissions you also need particular privs - and a few others like that. without permissions on the underlying server you can't see who is part of the local groups - in case someone is on a local group and was added to "elevated" SQL groups.. and so on.
As for permissions - scripts aren't that big with regards to perms - and luckily for me on this particular aspect we have a datawarehouse where we store ALL permissions in ALL db's in ALL servers we have on our estate (and a lot more info about the servers - SQL/Oracle/MySQL/MongoDB)- refreshed weekly and with new servers automatically added to it. Should a auditor request this its just a question of giving them access to the DW - where they can even compare week on week and see when perms were added/removed.
December 13, 2021 at 9:02 pm
ScottPletcher wrote:Hold on. I explicitly stated that auditors should not be able to change anything on the system. Talking about giving auditors "sysadmin" is a straw man.
Scripts that capture full permissions across hundreds of dbs (in our instances) can be very complex. I don't have time -- nor the inclination, frankly -- to review all their code. I do review their conclusions to make sure they are accurate.
We just completed an audit. I answered some qs but I did not run any of the code. Then again, they didn't have authority to change anything on the system, just to query it. I don't understand why anyone would feel they need to review code that just reads metadata during an audit. Is that just me?! I don't think so.
...have a datawarehouse where we store ALL permissions in ALL db's in ALL servers we have on our estate (and a lot more info about the servers - SQL/Oracle/MySQL/MongoDB)- refreshed weekly and with new servers automatically added to it. Should a auditor request this its just a question of giving them access to the DW - where they can even compare week on week and see when perms were added/removed.
C'mon, no self-respecting auditor is going to limit themselves to data pre-built by the site they are auditing.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
December 13, 2021 at 9:05 pm
ScottPletcher wrote:Hold on. I explicitly stated that auditors should not be able to change anything on the system. Talking about giving auditors "sysadmin" is a straw man.
Scripts that capture full permissions across hundreds of dbs (in our instances) can be very complex. I don't have time -- nor the inclination, frankly -- to review all their code. I do review their conclusions to make sure they are accurate.
We just completed an audit. I answered some qs but I did not run any of the code. Then again, they didn't have authority to change anything on the system, just to query it. I don't understand why anyone would feel they need to review code that just reads metadata during an audit. Is that just me?! I don't think so.
in order to do a full permissions you do need higher privs - without alter login you can't view logins, to see database permissions you also need particular privs - and a few others like that. without permissions on the underlying server you can't see who is part of the local groups - in case someone is on a local group and was added to "elevated" SQL groups.. and so on.
We did have to provide certain procs for the auditors to use to retrieve certain data, including AD info (such as it's available from SQL Server; DBAs don't have permission to AD here outside SQL Server itself). I honestly don't remember what all procs I had to create as part of this process or what specifically they returned; I initially created such procs almost 20 years ago.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
December 14, 2021 at 12:55 am
frederico_fonseca wrote:ScottPletcher wrote:Hold on. I explicitly stated that auditors should not be able to change anything on the system. Talking about giving auditors "sysadmin" is a straw man.
Scripts that capture full permissions across hundreds of dbs (in our instances) can be very complex. I don't have time -- nor the inclination, frankly -- to review all their code. I do review their conclusions to make sure they are accurate.
We just completed an audit. I answered some qs but I did not run any of the code. Then again, they didn't have authority to change anything on the system, just to query it. I don't understand why anyone would feel they need to review code that just reads metadata during an audit. Is that just me?! I don't think so.
...have a datawarehouse where we store ALL permissions in ALL db's in ALL servers we have on our estate (and a lot more info about the servers - SQL/Oracle/MySQL/MongoDB)- refreshed weekly and with new servers automatically added to it. Should a auditor request this its just a question of giving them access to the DW - where they can even compare week on week and see when perms were added/removed.
C'mon, no self-respecting auditor is going to limit themselves to data pre-built by the site they are auditing.
In your words.. "C'mon" :D... You're simply not listening. THEY provide the script, I review it for safety, and they come to my desk to watch me execute it. There is no self-respecting auditor that will disagree with that and ,many appreciate the extra safety concerns.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2021 at 1:20 am
ScottPletcher wrote:frederico_fonseca wrote:ScottPletcher wrote:Hold on. I explicitly stated that auditors should not be able to change anything on the system. Talking about giving auditors "sysadmin" is a straw man.
Scripts that capture full permissions across hundreds of dbs (in our instances) can be very complex. I don't have time -- nor the inclination, frankly -- to review all their code. I do review their conclusions to make sure they are accurate.
We just completed an audit. I answered some qs but I did not run any of the code. Then again, they didn't have authority to change anything on the system, just to query it. I don't understand why anyone would feel they need to review code that just reads metadata during an audit. Is that just me?! I don't think so.
...have a datawarehouse where we store ALL permissions in ALL db's in ALL servers we have on our estate (and a lot more info about the servers - SQL/Oracle/MySQL/MongoDB)- refreshed weekly and with new servers automatically added to it. Should a auditor request this its just a question of giving them access to the DW - where they can even compare week on week and see when perms were added/removed.
C'mon, no self-respecting auditor is going to limit themselves to data pre-built by the site they are auditing.
In your words.. "C'mon" :D... You're simply not listening. THEY provide the script, I review it for safety, and they come to my desk to watch me execute it. There is no self-respecting auditor that will disagree with that and ,many appreciate the extra safety concerns.
"I review it". How long does THAT take?
And why does it need reviewed for "safety" if they don't have the permissions to change anything on the instance??
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
December 14, 2021 at 4:45 am
"I review it". How long does THAT take?
And why does it need reviewed for "safety" if they don't have the permissions to change anything on the instance??
What on Earth are you going on about? It takes no time to review and the reason why I review it is for the same reason I don't immediately run any code I downloaded off the internet.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 14, 2021 at 3:58 pm
ScottPletcher wrote:"I review it". How long does THAT take?
And why does it need reviewed for "safety" if they don't have the permissions to change anything on the instance??
What on Earth are you going on about? It takes no time to review and the reason why I review it is for the same reason I don't immediately run any code I downloaded off the internet.
It takes no time to review 100s of lines of script? Baloney.
I don't think you've ever been involved in audits in a multi-billion dollar company. You don't tell the auditors that you will run all their code. It's just not done like that, especially after Sarb Ox. Companies that size must do full due diligence, and that includes not allowing the DBA to completely control an audit. Again, it's not a true "audit" if that's allowed. Smaller companies may get away with that, although it's still not good practice.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
December 14, 2021 at 4:49 pm
Jeff Moden wrote:ScottPletcher wrote:"I review it". How long does THAT take?
And why does it need reviewed for "safety" if they don't have the permissions to change anything on the instance??
What on Earth are you going on about? It takes no time to review and the reason why I review it is for the same reason I don't immediately run any code I downloaded off the internet.
It takes no time to review 100s of lines of script? Baloney.
I don't think you've ever been involved in audits in a multi-billion dollar company. You don't tell the auditors that you will run all their code. It's just not done like that, especially after Sarb Ox. Companies that size must do full due diligence, and that includes not allowing the DBA to completely control an audit. Again, it's not a true "audit" if that's allowed. Smaller companies may get away with that, although it's still not good practice.
in order to do a full audit they need to have the permissions - so either you give them the permissions or you setup a set of stored procs on each server and grant permissions to the stored proc (through cert signing) in order to do the full audit - in either case to prevent them from changing the server while still allowing the required permissions to do a FULL audit you would have a hell of a lot of work to set it up - while you may not agree with me and Jeff that reviewing it to ensure that a "smart" auditor didn't do something that could have significant impact on a production environment is a good and required step on an audit, that is the case in many companies - and I do work on a rather big company (6k users just on my sub branch and we are the smallest).
And no company would allow an auditor full reign on an HR server for example.
and again as Jeff tried to make it very clear we don't control the audit - but we do ensure it does not break our systems. (forensic audits are a different story)
December 14, 2021 at 8:31 pm
ScottPletcher wrote:Jeff Moden wrote:ScottPletcher wrote:"I review it". How long does THAT take?
And why does it need reviewed for "safety" if they don't have the permissions to change anything on the instance??
What on Earth are you going on about? It takes no time to review and the reason why I review it is for the same reason I don't immediately run any code I downloaded off the internet.
It takes no time to review 100s of lines of script? Baloney.
I don't think you've ever been involved in audits in a multi-billion dollar company. You don't tell the auditors that you will run all their code. It's just not done like that, especially after Sarb Ox. Companies that size must do full due diligence, and that includes not allowing the DBA to completely control an audit. Again, it's not a true "audit" if that's allowed. Smaller companies may get away with that, although it's still not good practice.
in order to do a full audit they need to have the permissions - so either you give them the permissions or you setup a set of stored procs on each server and grant permissions to the stored proc (through cert signing) in order to do the full audit - in either case to prevent them from changing the server while still allowing the required permissions to do a FULL audit you would have a hell of a lot of work to set it up - while you may not agree with me and Jeff that reviewing it to ensure that a "smart" auditor didn't do something that could have significant impact on a production environment is a good and required step on an audit, that is the case in many companies - and I do work on a rather big company (6k users just on my sub branch and we are the smallest).
And no company would allow an auditor full reign on an HR server for example.
and again as Jeff tried to make it very clear we don't control the audit - but we do ensure it does not break our systems. (forensic audits are a different story)
One super-quick review of code can't possibly make sure code doesn't break something. Again, I've never seen auditing scripts that were short enough to be quickly reviewed. If you can't trust that the auditing company won't destroy/damage your system, then don't hire them in the first place.
So what if you do review and say "no", then what??
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
December 14, 2021 at 8:38 pm
ScottPletcher wrote:Jeff Moden wrote:ScottPletcher wrote:"I review it". How long does THAT take?
And why does it need reviewed for "safety" if they don't have the permissions to change anything on the instance??
What on Earth are you going on about? It takes no time to review and the reason why I review it is for the same reason I don't immediately run any code I downloaded off the internet.
It takes no time to review 100s of lines of script? Baloney.
I don't think you've ever been involved in audits in a multi-billion dollar company. You don't tell the auditors that you will run all their code. It's just not done like that, especially after Sarb Ox. Companies that size must do full due diligence, and that includes not allowing the DBA to completely control an audit. Again, it's not a true "audit" if that's allowed. Smaller companies may get away with that, although it's still not good practice.
in order to do a full audit they need to have the permissions - so either you give them the permissions or you setup a set of stored procs on each server and grant permissions to the stored proc (through cert signing) in order to do the full audit - in either case to prevent them from changing the server while still allowing the required permissions to do a FULL audit you would have a hell of a lot of work to set it up - while you may not agree with me and Jeff that reviewing it to ensure that a "smart" auditor didn't do something that could have significant impact on a production environment is a good and required step on an audit, that is the case in many companies - and I do work on a rather big company (6k users just on my sub branch and we are the smallest).
And no company would allow an auditor full reign on an HR server for example.
and again as Jeff tried to make it very clear we don't control the audit - but we do ensure it does not break our systems. (forensic audits are a different story)
I have been involved in audits in a large company. I've also been involved in ISO 9000, QS 9000, TE 9000, SOX and ISO 27001 audits.
Nobody, and I mean nobody, I've ever met would give free reign on a server to an auditor. Any admin (DBA, domain admin, root, etc.) worth his salt would review everything that gets run on their server. The first duty of a DBA is to protect the data. Whether someone has privs to change data or not doesn't matter if you've seen a data breach news story in the past several years. A directive to give an elevated privs to someone would need to come from a corporate security officer at a minimum, but preferably a CTO or CEO. In my experience, it's just not done.
If an auditor has code to query what they need, it gets reviewed. Period. If they a custom report written from a system, it gets written and reviewed by separate people and approved by the boss before it's run for the auditor. I've never in my life seen a case where an auditor was given direct access to a server. I've seen them give scripts to domain admins and DBAs and say they need the results, but the one to run the script gets to review it first. I can speak for myself when I say I always review anything an auditor asks me to run.
Then again, I find that working with an auditor instead of fighting against them often helps the whole process, especially when it comes to security audits. Think about it - if they find something, then I can fix it before someone else finds it and takes advantage of it.
December 14, 2021 at 8:42 pm
frederico_fonseca wrote:ScottPletcher wrote:Jeff Moden wrote:ScottPletcher wrote:"I review it". How long does THAT take?
And why does it need reviewed for "safety" if they don't have the permissions to change anything on the instance??
What on Earth are you going on about? It takes no time to review and the reason why I review it is for the same reason I don't immediately run any code I downloaded off the internet.
It takes no time to review 100s of lines of script? Baloney.
I don't think you've ever been involved in audits in a multi-billion dollar company. You don't tell the auditors that you will run all their code. It's just not done like that, especially after Sarb Ox. Companies that size must do full due diligence, and that includes not allowing the DBA to completely control an audit. Again, it's not a true "audit" if that's allowed. Smaller companies may get away with that, although it's still not good practice.
in order to do a full audit they need to have the permissions - so either you give them the permissions or you setup a set of stored procs on each server and grant permissions to the stored proc (through cert signing) in order to do the full audit - in either case to prevent them from changing the server while still allowing the required permissions to do a FULL audit you would have a hell of a lot of work to set it up - while you may not agree with me and Jeff that reviewing it to ensure that a "smart" auditor didn't do something that could have significant impact on a production environment is a good and required step on an audit, that is the case in many companies - and I do work on a rather big company (6k users just on my sub branch and we are the smallest).
And no company would allow an auditor full reign on an HR server for example.
and again as Jeff tried to make it very clear we don't control the audit - but we do ensure it does not break our systems. (forensic audits are a different story)
I have been involved in audits in a large company. I've also been involved in ISO 9000, QS 9000, TE 9000, SOX and ISO 27001 audits.
Nobody, and I mean nobody, I've ever met would give free reign on a server to an auditor. Any admin (DBA, domain admin, root, etc.) worth his salt would review everything that gets run on their server. The first duty of a DBA is to protect the data. Whether someone has privs to change data or not doesn't matter if you've seen a data breach news story in the past several years. A directive to give an elevated privs to someone would need to come from a corporate security officer at a minimum, but preferably a CTO or CEO. In my experience, it's just not done.
If an auditor has code to query what they need, it gets reviewed. Period. If they a custom report written from a system, it gets written and reviewed by separate people and approved by the boss before it's run for the auditor. I've never in my life seen a case where an auditor was given direct access to a server. I've seen them give scripts to domain admins and DBAs and say they need the results, but the one to run the script gets to review it first. I can speak for myself when I say I always review anything an auditor asks me to run.
Then again, I find that working with an auditor instead of fighting against them often helps the whole process, especially when it comes to security audits. Think about it - if they find something, then I can fix it before someone else finds it and takes advantage of it.
Again, they cannot modify anything! I don't have the time to review dozens or hundreds of scripts with dozens or hundreds of lines each.
It is done. I just did it. We just went through an audit. I answered several questions, we worked out the protocols for how the methods they would use to access other-protected data. That was it.
Believe me, you didn't interfere with Sarb Ox auditors either. Try telling a Sarb Ox auditor that you want to review and approve all their code.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
December 14, 2021 at 8:44 pm
Ed Wagner wrote:frederico_fonseca wrote:ScottPletcher wrote:Jeff Moden wrote:ScottPletcher wrote:"I review it". How long does THAT take?
And why does it need reviewed for "safety" if they don't have the permissions to change anything on the instance??
What on Earth are you going on about? It takes no time to review and the reason why I review it is for the same reason I don't immediately run any code I downloaded off the internet.
It takes no time to review 100s of lines of script? Baloney.
I don't think you've ever been involved in audits in a multi-billion dollar company. You don't tell the auditors that you will run all their code. It's just not done like that, especially after Sarb Ox. Companies that size must do full due diligence, and that includes not allowing the DBA to completely control an audit. Again, it's not a true "audit" if that's allowed. Smaller companies may get away with that, although it's still not good practice.
in order to do a full audit they need to have the permissions - so either you give them the permissions or you setup a set of stored procs on each server and grant permissions to the stored proc (through cert signing) in order to do the full audit - in either case to prevent them from changing the server while still allowing the required permissions to do a FULL audit you would have a hell of a lot of work to set it up - while you may not agree with me and Jeff that reviewing it to ensure that a "smart" auditor didn't do something that could have significant impact on a production environment is a good and required step on an audit, that is the case in many companies - and I do work on a rather big company (6k users just on my sub branch and we are the smallest).
And no company would allow an auditor full reign on an HR server for example.
and again as Jeff tried to make it very clear we don't control the audit - but we do ensure it does not break our systems. (forensic audits are a different story)
I have been involved in audits in a large company. I've also been involved in ISO 9000, QS 9000, TE 9000, SOX and ISO 27001 audits.
Nobody, and I mean nobody, I've ever met would give free reign on a server to an auditor. Any admin (DBA, domain admin, root, etc.) worth his salt would review everything that gets run on their server. The first duty of a DBA is to protect the data. Whether someone has privs to change data or not doesn't matter if you've seen a data breach news story in the past several years. A directive to give an elevated privs to someone would need to come from a corporate security officer at a minimum, but preferably a CTO or CEO. In my experience, it's just not done.
If an auditor has code to query what they need, it gets reviewed. Period. If they a custom report written from a system, it gets written and reviewed by separate people and approved by the boss before it's run for the auditor. I've never in my life seen a case where an auditor was given direct access to a server. I've seen them give scripts to domain admins and DBAs and say they need the results, but the one to run the script gets to review it first. I can speak for myself when I say I always review anything an auditor asks me to run.
Then again, I find that working with an auditor instead of fighting against them often helps the whole process, especially when it comes to security audits. Think about it - if they find something, then I can fix it before someone else finds it and takes advantage of it.
Again, they cannot modify anything! I don't have the time to review dozens or hundreds of scripts with dozens or hundreds of lines each.
It is done. I just did it. We just went through an audit. I answered several questions, we worked out the protocols for how the methods they would use to access other-protected data. That was it.
Believe me, you didn't interfere with Sarb Ox auditors either. Try telling a Sarb Ox auditor that you want to review and approve all their code.
I have.
December 14, 2021 at 8:57 pm
frederico_fonseca wrote:ScottPletcher wrote:Jeff Moden wrote:ScottPletcher wrote:"I review it". How long does THAT take?
And why does it need reviewed for "safety" if they don't have the permissions to change anything on the instance??
What on Earth are you going on about? It takes no time to review and the reason why I review it is for the same reason I don't immediately run any code I downloaded off the internet.
It takes no time to review 100s of lines of script? Baloney.
I don't think you've ever been involved in audits in a multi-billion dollar company. You don't tell the auditors that you will run all their code. It's just not done like that, especially after Sarb Ox. Companies that size must do full due diligence, and that includes not allowing the DBA to completely control an audit. Again, it's not a true "audit" if that's allowed. Smaller companies may get away with that, although it's still not good practice.
in order to do a full audit they need to have the permissions - so either you give them the permissions or you setup a set of stored procs on each server and grant permissions to the stored proc (through cert signing) in order to do the full audit - in either case to prevent them from changing the server while still allowing the required permissions to do a FULL audit you would have a hell of a lot of work to set it up - while you may not agree with me and Jeff that reviewing it to ensure that a "smart" auditor didn't do something that could have significant impact on a production environment is a good and required step on an audit, that is the case in many companies - and I do work on a rather big company (6k users just on my sub branch and we are the smallest).
And no company would allow an auditor full reign on an HR server for example.
and again as Jeff tried to make it very clear we don't control the audit - but we do ensure it does not break our systems. (forensic audits are a different story)
One super-quick review of code can't possibly make sure code doesn't break something. Again, I've never seen auditing scripts that were short enough to be quickly reviewed. If you can't trust that the auditing company won't destroy/damage your system, then don't hire them in the first place.
So what if you do review and say "no", then what??
I have been involved with audits, of many types, for billion dollar corporations. And I have said NO to an auditor.
There was a team of auditors. They came in with a set of pre-written scripts for Oracle and SQL. One of the auditors seemed to think that his job was to "trip up" anyone and anything. He was a real jerk. Well, he wanted to have sysadmin or root rights, and just run his scripts. In this case. they didn't do much but list users, roles and permissions. I said no. He went running to the lead auditor, who in turn came to me. Guess who won?
The second, more common, situation was that the auditors requested certain information. We wrote scripts, provided the documentation of the scripts, and they reviewed the scripts and documentation. After a little back and forth to clarify the requirements, we (myself and the auditors) ran the scripts together, exported the results, and all was good.
I'm not sure what experiences you have, but I have never worked anywhere that dreaded an audit. And I never had an auditor who was "looking for trouble". The entire point of the audits are to identify issues of that can be of many different types, and use the findings of the audit to validate rules and improve processes.
Your continuing arguing over this subject really seems like you just want to be right.
Ok, you're right. But nobody else is wrong either. We've been at this as long, or longer in a lot of cases, as you have. We've only related our experiences.
Oh yeah. One more thing. Most of these have been Sar-Box audits. Again, not sure what you have run into, but it certainly seems different than mine.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
http://www.sqlservercentral.com/articles/61537/
December 14, 2021 at 9:30 pm
ScottPletcher wrote:frederico_fonseca wrote:ScottPletcher wrote:Jeff Moden wrote:ScottPletcher wrote:"I review it". How long does THAT take?
And why does it need reviewed for "safety" if they don't have the permissions to change anything on the instance??
What on Earth are you going on about? It takes no time to review and the reason why I review it is for the same reason I don't immediately run any code I downloaded off the internet.
It takes no time to review 100s of lines of script? Baloney.
I don't think you've ever been involved in audits in a multi-billion dollar company. You don't tell the auditors that you will run all their code. It's just not done like that, especially after Sarb Ox. Companies that size must do full due diligence, and that includes not allowing the DBA to completely control an audit. Again, it's not a true "audit" if that's allowed. Smaller companies may get away with that, although it's still not good practice.
in order to do a full audit they need to have the permissions - so either you give them the permissions or you setup a set of stored procs on each server and grant permissions to the stored proc (through cert signing) in order to do the full audit - in either case to prevent them from changing the server while still allowing the required permissions to do a FULL audit you would have a hell of a lot of work to set it up - while you may not agree with me and Jeff that reviewing it to ensure that a "smart" auditor didn't do something that could have significant impact on a production environment is a good and required step on an audit, that is the case in many companies - and I do work on a rather big company (6k users just on my sub branch and we are the smallest).
And no company would allow an auditor full reign on an HR server for example.
and again as Jeff tried to make it very clear we don't control the audit - but we do ensure it does not break our systems. (forensic audits are a different story)
One super-quick review of code can't possibly make sure code doesn't break something. Again, I've never seen auditing scripts that were short enough to be quickly reviewed. If you can't trust that the auditing company won't destroy/damage your system, then don't hire them in the first place.
So what if you do review and say "no", then what??
I have been involved with audits, of many types, for billion dollar corporations. And I have said NO to an auditor.
There was a team of auditors. They came in with a set of pre-written scripts for Oracle and SQL. One of the auditors seemed to think that his job was to "trip up" anyone and anything. He was a real jerk. Well, he wanted to have sysadmin or root rights, and just run his scripts. In this case. they didn't do much but list users, roles and permissions. I said no. He went running to the lead auditor, who in turn came to me. Guess who won?
The second, more common, situation was that the auditors requested certain information. We wrote scripts, provided the documentation of the scripts, and they reviewed the scripts and documentation. After a little back and forth to clarify the requirements, we (myself and the auditors) ran the scripts together, exported the results, and all was good.
I'm not sure what experiences you have, but I have never worked anywhere that dreaded an audit. And I never had an auditor who was "looking for trouble". The entire point of the audits are to identify issues of that can be of many different types, and use the findings of the audit to validate rules and improve processes.
Your continuing arguing over this subject really seems like you just want to be right.
Ok, you're right. But nobody else is wrong either. We've been at this as long, or longer in a lot of cases, as you have. We've only related our experiences.
Oh yeah. One more thing. Most of these have been Sar-Box audits. Again, not sure what you have run into, but it certainly seems different than mine.
Yes, the first gambit of a many auditors is to request sysadmin or other super-high-level authority. Only one place I worked at ever allowed that, and even they eventually decided against it.
The second situation is almost exactly the same as mine. In no case did I ever review all their code, that's just not practical. Frankly I think I'd rather have a tooth pulled anyway. I don't want to see how egregious much of their code probably likely is.
SQL DBA,SQL Server MVP(07, 08, 09) A socialist is someone who will give you the shirt off *someone else's* back.
Viewing 14 posts - 16 through 28 (of 28 total)
You must be logged in to reply to this topic. Login to reply