October 11, 2011 at 1:36 am
Morning, got an interesting question. I have been asked to sign a witness statement confirming that the state of collected data is correct , not been tampered with etc. Obviously cannot go into any detail for legal reasons but having never been exposed to this request before i was wondering how other DBAs handle these requests and anything I should be wary off, any questions i should be asking ?
Thank you for any advice.
Scott
October 12, 2011 at 5:38 pm
Never heard of this before
October 12, 2011 at 7:57 pm
doesn't this have to be previewed by your company's attorney before you sign anything? in my shop, a lot of people above me would be involved before i ever got called in to sign anything like that....
Lowell
October 13, 2011 at 12:51 am
Thank you for the reply. I honestly have no idea , its my directors that have asked me to sign is as the DBA.
Basically what i would be signing is:
1) the customer created report is accurate. (well that is itself is wrong, i think we would have to create the report ourself).
2) the hardware is sending accurate data. (embedded code development that i cannot verify)
3) the data in the DB has not been tampered with (I restrict access to the data so no worries there).
4) I guess the other element is our developers code. New code goes through various loops, tick boxes and testing but i don't read every line.
From the feedback on this forum it doest sound like a very common occurance. I guess its the market we are in though hence we get exposed to these requests.
Thanks for the feedback.
Scott
October 13, 2011 at 7:10 am
Sounds like a Sarbanes-Oxley-related item. Since the leadership of a company is now criminally liable for the data used to run their company, they are now taking steps to make sure that they can be (1) sure that their data is correct, untampered with, and valid, and (2) they have downstream scapegoats identified ("Hey, he signed off on it!") should anything go wonky. Putting my conspiracy theorist hat on for a moment, it seems like they are putting you in a position of responsibility (which may be perfectly valid and correct) without much "fallback".
IANAL, but if you have any qualms about signing off on something that you don't have control over, I'd talk to your manager, director and/or HR rep to voice your concerns, and engage a lawyer to find out what your exposure might be for signing it.
October 13, 2011 at 9:00 am
I second the suggestion that you confer with your own lawyer about your obligations and potential liability around signing such a statement. The company's lawyers represent the company, not you personally, so you shouldn't automatically rely on any assurances or advice you get from them.
That being said, such documents are almost always drafted by lawyers, who as a group are notoriously ignorant of technology. The authors of the statement presented to you probably do not comprehend the technical issues involved with the affirmations they ask you to make. You will probably have to push back as tactfully as possible and spend some time educating those authors about the technology involved. You will probably need to explain to them in some detail the scope of your knowledge of and control over the systems involved and how that affects your ability to verify the matters you are being asked to affirm. You definitely don't want to make statements, under oath or otherwise, about systems or processes that you don't control or understand, other than, "I don't control or understand that system or process well enough to affirm anything about it one way or another."
The lawyers should know that a statement from a witness who has no personal knowledge of the subject matter is useless and should start looking for the people who can address the matters you cannot. You stand a good chance of getting into hot water in a situation like this if you make statements that you cannot back up with facts and detailed knowledge when asked about them later (by a government agent or a lawyer for a legal adversary of the company, especially). The company lawyers have no way of knowing that your statements are factually sound other than your say-so, and if they perceive that you made any of those statements without fully informing them of any limitations or qualifications of your knowledge of the underlying facts, they will turn on you savagely when an adversary undercuts the value of your statement to the company by exposing those limitations or qualifications.
I'm reminded of a request from company lawyers to provide copies of all invoices submitted by the company to a customer for production to the customer's lawyers in litigation. In discussions about this request, it became clear that both the company's and the customer's lawyers were thinking of invoices in a traditional sense - a sheet or sheets of paper with the customer's address, an invoice number, an invoice date, line items detailing each charge, and a balance due. There were no "invoices" in this sense - only rows in a database that were periodically queried by an application that packaged the data in a defined format for electronic data interchange and submitted it to the customer's accounting system via a web service. If the company's lawyers relied on a technically true statement that "We don't have any such sheets of paper" and told the customer's lawyers that the company had no invoices to produce, the legal ramifications could have been disastrous when it later came out in testimony that the billing information exists in the database.Imagine the angry "Why didn't you tell me . . . " conversation (and possible termination of employment) that would have occurred in this situation! Once the company's lawyers understood that there is no filing cabinet from which to pull the requested "invoices" but that the actual information that would appear on such a document existed in the database, they were able to make the necessary legal judgments about what to do with that information in response to the request for "invoices," and responsibility for the ramifications and consequences of that judgment lay with them rather than the database administrators and system administrators.
Jason Wolfkill
October 17, 2011 at 2:41 am
Thanks again for the posts, certainly plenty to consider. I think the only think i can validate is the integrity of the data we have stored leaving the hardware aspect out of the loop. Any amendment to the statement should state this.
October 17, 2011 at 6:56 am
I would caution aabout signing about data integrity. Unless some mechanism in place that can affirm that the data you retrieve today is exactly the same as the data stored on a given date, then you are signing for something you have no real control over.
Typical data integrity mechanism include encryption, where the timestamp of the encryption is stored as meta-data, or hashing where the data is unencrypted but you link that with an encrypted tag that includes the timestamp and hash value.
If all you have is unencrypted data, there are too many ways for that data to be changed, and too many ways where you have no chance of proving the data has not been changed.
If you make any change to the page containing the sensitive rows (add a new row, rebuild the index, etc) then the LSN for the page is changed and you have no real way (apart from keeping ALL log backups for ever) of proving that data on a sensitive row has not changed. At a deeper level, the physical disks used to store your data are likely to get changed over time, and you again have difficult proving that data was not also changed during this exercise.
If it is critical for your organisation to prove that sensitive data has not changed, then they need to use a programatic mechanism that can show that the data has not been changed. Failing this, all you can sign is 'To the best of my knowlege and belief...'.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
October 18, 2011 at 12:06 am
You need to make sure there is some language in the document that refers to something like the follwoing points
- All DML is completed according to requirements as applied in application code. These requirements are maintained by and are the responsibility of <name>. This is in accordance with standard business process for this company.
- I accept the application requirements on good faith on this basis.
- All DML outside the applications requirements is only allowed on the express and authorised consent of relevant stakeholders.
Now you need to be completely on top of allowing access to the data for DML statements. Log when accounts and groups are given DML rights and when they are removed. You should not be held responsible for AD group membership, if you are, log this too. You also need to push back on the business making it clear that with this responsibilty, there has to be the equal authority. Get it in writing.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply