September 9, 2008 at 11:11 pm
Comments posted to this topic are about the item Legal Security
September 10, 2008 at 2:37 am
I'm not sure it's quite as scary as it might at first appear.
At least in the UK, it is the company as a legal entity, not an employee, that is held responsible for ensuring data processing complies with relevant data laws. Therefore, deciding which laws are relevant and which practices are (un)acceptable is a question first and foremost for the resident legal eagle. The DBA does not make those decisions, but merely implements the practices after the decisions have been made.
OK, that's simplistic, since any company with an ounce of common sense will get the legals and the DBAs talking together to thrash out a practical solution. However, the fundamental still remains - the DBA is the implementer NOT the initiator or decision maker. I'm not trying to duck responsibility; merely to underline that neither should a company.
That said, I do agree that industry standards are the way to go, even if one company's implementation merely uses them as templates and varies the details.
Semper in excretia, suus solum profundum variat
September 10, 2008 at 4:05 am
Data protection forms part of Information Lifecycle Management (ILM). ILM covers not just who should be able to access the information, but also how long the information should survive, how it should be disposed of, and what is the most appropriate storage media at the various stages in its lifecycle.
Typically within an ILM environment, each data object will be assigned to a ILM management policy. The management policy will determine the confidentiality, lifecycle and disposition of the data item. It is then a lot easier for staff such as DBAs to understand how they should manage the data object (e.g. database, backup, etc), and for the company to deal with non-compliance to procedures by staff.
If the business does not have any formal ILM policy it is not the duty of the DBA to create one and police it, as much of what ILM covers is way outside the DBAs job remit. A DBA can raise the need for ILM policies with management and play a part in formulating company ILM policies. However, it is the duty of management to decide on the priority of establishing ILM policies and the resources to be devoted to it.
If writs do start flying, the business is the legal entity that is liable. Most jurisdictions require the business to establish a competant data protection officer, and it is that person who is most at risk of personal liability. A DBA is too far down the food chain to be subject to personal liability, providing they have complied with established company proceduers. If a DBA is worried their employer is ignoring legal requirements then gather written evidence of raising your concerns with management. Or get another job.
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
September 10, 2008 at 9:32 am
It does not matter who is culpable. If you blow it legally you might get off, but most bosses will free up your future very quickly.
Not all gray hairs are Dinosaurs!
September 10, 2008 at 10:15 am
Well, I think we've been talking about 2 different issues here.
(1)Is a DBA the only one really responsible for the implementation of policies and legal obligations? The answer is NO.
(2)Can the DBA have partial responsability in bad implementations of security when we talk about sensitive data? The answer is absolutely YES.
With standards such as SOX and etc., the problem is that usually inside the companies, it is not clearly specified the red line of the responsibility for the IT(DBA, System Administrator) teams, cause those teams basically response to management directives. Furthermore, all those standards have type-B implementations that can align specific business processes with the standard in case; however sometimes the group that implement the business process doesn't realize that there are technical issues to be covered as well, and that's why sometimes the infrastructure teams are not really aware of what really means: 'Let's celebrate. We completed the implementation of the XYZ Law!!!'.
There is another important point here, and this is specific for the DBA units around the world: COMMUNICATION.
If you think something is not OK, or doesn't reflect the purpose of one standard already implemented, then tell it to someone. I think all of us have seen important/confidential information that is clear, uncrypted, or with bad security implementation.
My point is if any information is compromised, or any hacker attack occur, someone might ask you: Did you know that was configured the wrong way? Did you know that was not a best practice? Could you do anything to stop this from happening?
Unfortunately, you'll have to answer YES to all of the questions.
For instance, once I knew of some developer of a business critical application, who preferred to assign FULL OBJECT LEVEL-permissions to the PUBLIC role because that way he didn't have to deal with different permissions or roles. I explained to him that any user with access to the database had practically DBO permissions over the entire database. He didn't agree with me. At the end, I simply wrote an email to my boss, the developer's boss, and the IT Security Team; and I put it in my Personal Folder which I back it up frequently. End of the story.
September 10, 2008 at 9:48 pm
I'm certain there are plenty of businesses 'out there' who don't really comprehend the value of their data. Therefore, it is not treated as a valuable asset. Until that mindset firmly takes hold we will continue to see stories of data negligence, data breaches, and data theft in the news.
Maybe someone knows, but is there even a line in the balance sheet for "Value of Data"? It's sort of intangible though you can use it. It's somewhere between an office chair and goodwill 🙂
James Stover, McDBA
September 15, 2008 at 6:32 am
A comment to "someone like ANSI developing guidelines for data security".
September 15, 2008 at 6:49 am
That looks interesting. Reminds me of ISO9001, which a couple companies I worked for adhered to. While it was annoying on day to day basis, I think it does help improve the overall level of security just because you have to pay attention to things.
Our biggest problem was that it's so general that you often have people that don't really think things through. It's a chore, so they don't take it as a challenge to implement better controls, they implement the easiest ones.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply