Security Overview for an Aspiring DBA by Helen Kresl

My goal at the end of this program is to join the work force as an entry level DBA (Database Administrator) in a SQL Server environment. My tasks will be to implement and manage a database so that the information in it is never lost,  is configured well so that queries against it run efficiently,  is available to the company’s applications and business analysts with the least amount of lag time, and is secure from outside security threats.   Of these tasks I will probably have the least say about how to configure and implement security.   The task of envisioning a strategy and program for securing information assets is the job of a Chief Information Security Office (Wiki 1)  and senior DBA. My job will be to implement their vision within SQL Server or third party software.   My primary concern around security will be to understand why I am doing it which is what I plan to examine here.  The following is a cursory examination of the legal landscape as it pertains to information security in organizations which use private information of the consumers in the course of their operations. 

In the US there are four sets of federal laws that govern the protection of private information across all sectors of business:  The Sarbanes-Oxley Act (SOX) of 2002 sets up standards and penalties for publicly owned companies tampering with data (Wiki 2). The Health Insurance Portability and Accountability Act (HIPAA) of 1999 particularly the Administration Simplification provision protects the security and privacy of medical information (Wiki 3).  Title V of Gramm-Leach-Bliley (GLB Act)  of 1999 requires financial institutions to develop specific administrative, technical, and physical safeguards to protect security of customer information such as salaries, social security numbers, and contact information (Wiki 4). And, the Children's Online Privacy Protection Act (COPPA) of 1998, describes the responsibilities of entities when taking private information from children 13 and under or when marketing to them (Wiki 5 & Black 6).

Besides these US regulations there may be additional ones governed by the individual states or other countries if the operations have offices worldwide.  There is a worldwide standard called the Payment Card Industry Data Security Standard (Wiki 7) which applies at least twelve configuration requirements to computer and procedural systems of any organization that receives and processes credit card information associated with the major logos: VISA, MC, and American Express.  Under a certain number of credit transactions compliance is self-administered.  At any rate, everyone on this planet using VISA, MC, and AX is in one way or another obligated to keep information secure.  If I’m working for any large business at least three of these regulations (HIPAA, GLBA, PCI DSS) will apply all of the time. 

 

The cost of protecting a company’s reputation is high just from a public image standpoint and a marketing cost.  In this way, as of 2009, “data breaches cost companies an average of $182 per compromised record, a 31% increase over 2005, according to the survey conducted by the Elk Rapids, Mich.-based Ponemon Institute (Wiresoft 8).”  But it is more difficult to see how federal and state agencies impose criminal and monetary penalties.  My research has yielded no evidence how the regulations actually enforce their standards and impose further criminal and monetary penalties unless breaches of private information is proven to be intentional.  Furthermore, though the rules, standards, and regulations are passed into law on a federal level it appears enforcement is left to individual states.  For example, here in Washington RCW code 19.255.010 requires that any entity conducting business using a computer that holds personal information must report any breach of security of that personal info to the persons involved as soon as possible but only if the breach subjects the customer to a risk of criminal activity.  But it is hard to see what the cost to the business entity would be in failure to do so.  RCW 19.300.020 states that anyone who intentionally ‘scans another person’s identification device” without that person’s prior knowledge or consent in order to commit fraud is guilty of a class C felony which carries with it a punishment of up to 10 years in jail.  It appears that the greatest cost to a company failing to adhere to the policies is from a public image standpoint. The burden of penalties falling on the individuals committing the crime of illegally intercepting and using private information as in the case of Albert Gonzalez who masterminded the SQL Injection attacks of 2009 against MS SQL Server 2005 code and used credit card information to support a lavish lifestyle. His sentencing will be held in three different states and he will at the very least face charges for computer fraud that impose up to five years in prison and a maximum fine of $250,000. (Gaudin 9)

 

In the case of a DBA in an IT department the motivation for protecting information, besides the fear of being fired, is mostly a matter of work ethic and personal integrity to the company.   Since my focus is to work for a large company using MS SQL Server, I will focus on SQL Server here.  This application is a database application designed with many security tools including those for data encryption which is necessary for compliance with PCI DSS.  Encryption can be used to encrypt a whole database or just columns within tables. When encryption is used credit card data can remain confidential even from users that have  SELECT permission on the tables containing credit card number columns using encryption.  This prevents insiders from getting and abusing data which is important as insiders account for 75% of attacks on personal data (Yuhanna 10).  However, a DBA with administrative access cannot be restricted from seeing this encrypted data.  This is where auditing comes in.

According to SOX (Wiki 2), when a publicly traded company is under investigation,  no one is allowed to tamper with its’ data without there being a record.  Therefore, if I work for a publicly held financial services company the due diligence of auditing of data will be of additional importance.  Using automated auditing capabilities in SQL Server one can track every time someone with permissions views and changes data.  Auditing can be applied to even a DBA’s username therefore the functionality is there to track all the actions of all database users.  Though auditing will not prevent the loss of theft of data it can be used to track who has accessed it, thereby act as a deterrent, for forensics, at the very least a SOX compliance measure.

The area of database management that I feel the least equipped to protect is in determining when database base code or web application software is making my system vulnerable.  This vulnerability of SLQ Server, which made the SQL Server Injection hacker, previously mentioned Albert Gonzalez, able to get credit card informational has to do with “a web application failing to properly filter or validate the data a user might enter on a web page” (Computer Economics 11).   Not to diminish my inadequacy here, but these kinds of attacks represent only a small percentage of threats to the database.  An informal email with a local employee of Microsoft indicated that this type of security breach occurs only about 2% of the time.  So, the bulk of the concern in protecting data is from other within the company.

 

So, what can a company do to protect its data?  It can hire skilled and honest employees, implement the right software and hardware, and consider buying insurance (Black 6). What can I do to provide the best service to the company I work for?  Continue to develop my coding and administrative skills, stay abreast of the database technology, and keep abreast of security breaches and patches.  But, since one report indicated “DBAs are spending approx. 5% of their time on database security (Yuhanna 12).”  I am concerned, that with pressures to maintain database performance, database availability to internal business processes, and database integrity, that I will not have much more than 5% of time working on constant surveillance of the system to outside attacks.  I believe that an awareness of the regulations governing privacy of information and the limitations of their own time to spend on the security aspect of database management should make every DBA open to working closely with their Chief Information Security Officer. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

CITATIONS

 

1.Wikipedia contributors. "Chief information security officer." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 12 Jan. 2010. Web. 31 Jan. 2010

 

2. Wikipedia contributors. "Sarbanes–Oxley Act." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 26 Jan. 2010. Web. 31 Jan. 2010

 

3. Wikipedia contributors. "Health Insurance Portability and Accountability Act." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 22 Jan. 2010. Web. 31 Jan. 2010

 

4. Wikipedia contributors. "Gramm–Leach–Bliley Act." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 25 Jan. 2010. Web. 31 Jan. 2010

 

5. Wikipedia contributors. "Children's Online Privacy Protection Act." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 20 Jan. 2010. Web. 31 Jan. 2010

 

6.Black, John E., Masters, Lorelie., Weitzel, David. “Dangers Lurk In Cyberspace: A Primer on Risks and Insurance”, ABA Business Law Section. Vol. 11, No. 6 – Jul/Aug 2002., Online 2010

 

7. Wikipedia contributors. "Payment Card Industry Data Security Standard." Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 24 Jan. 2010. Web. 31 Jan. 2010

 

8. www.wiresoft.com/_literature_39003/GLBA_Fact_Sheet - 51k

 

9. Gaudin, Sharon.,  www.ComputerWorld.com., article 9136737 “Three indicted for hack attacks on Heartland, Hannaford: Largest data breach conspiracy hit 5 companies, led to theft of 130M credit card numbers”, ComputerWorld. August 17, 2009

10. Yuhanna, Noel., “The Forrester Wave™: Database Auditing And Real-Time Protection, Q4 2007”, Forrester., Oct. 25, 2007

11. White Paper “Mitigating Security Threats by Minimizing Software Attack Surfaces” Computer Economics Reports; May 2008, Vol. 30 Issue 5, p15-19, 5p

 

12. Yuhanna, Noel., “The Forrester Wave™: Database Auditing And Real-Time Protection, Q4 2007”, Forrester., Oct. 26. 2007

 

NON-CITED SOURCE

 

Hotek, Michael., Microsoft SQL Server 2008-Implementation and Maintenance Training Kit, Microsoft Press., 2009