Home > SQL Server Tips > Database Administrator > Meet compliance with improved database security practices
SQL Server Tips:
EMAIL THIS
 TIPS & NEWSLETTERS TOPICS 

DATABASE ADMINISTRATOR

Meet compliance with improved database security practices


By Kevin Beaver, CISSP
12.12.2006
Rating: -4.00- (out of 5)


Expert advice on database administration
Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google


Whether management at your organization has bought into it or not, information security compliance is here to stay. It seems that every type of organization and every aspect of business is covered one way or another.

You're left to comply with myriad information security regulations, including:

  • Nearly three dozen state breach notification laws
  • HIPAA Security Rule mandating the protection of personal healthcare records
  • Gramm-Leach-Bliley Act covering personal financial information
  • PCI Data Security Standard requiring the lockdown of credit card information for merchants

    Practically every organization is being held to higher standards of information security.

    This concerns you as a DBA or network administrator responsible for database security because the database is where most, if not all, sensitive information covered by these laws and regulations is stored. The database is where the "gold" is, and it's also where you can focus your attention on making improvements. You have the ability to bring positive change -- both for your organization and your career.

    Here's what you can do to lay the groundwork to secure your databases:

    Compliance essentials

    If you're like many others, the compliance beast seems daunting. This is especially true if you're just starting down the path. Contrary to a popular misconception, compliance in the database realm is more than a firewall, column encryption or strong passwords.

    Having said that, the basic compliance requirements in the database security context are likely nothing new to you:

  • Risk assessment to determine which data is vulnerable and needs to be protected
  • Authentication controls for database logins
  • Access controls for database rights and administration roles
  • Audit logging for tracking who did what, when, where and how
  • Physical security controls to keep your servers and data protected from physical intruders
  • Secure software development practices to stop most database and application weaknesses where they start – at the code level
  • Incident response procedures for recovering from hack attempts, such as password cracking or SQL injection, as well as malware outbreaks on your database servers
  • Business continuity procedures for responding quickly and failing over to backup systems; at the very least, have procedures to keep your databases limping along so information is still accessible and its integrity is not jeopardized during a disaster
  • Ongoing testing and evaluations to find out what new and known vulnerabilities are present in your databases; these tests/evaluations also pertain to supporting applications and underlying operating systems and show you where you stand regarding overall information risk
  • All of these are information security best practices. You can look through HIPAA, GLBA, PCI – you name it -- and find the same basic requirements. No tricks, no magic, just common sense stuff that should be in place to support the business. Compliance brings these good security practices together to formalize your IT processes, especially where documentation of policies and procedures are concerned.

    Get going on security compliance: Inch by inch, row by row

    First of all, don't try to boil the ocean with widespread changes. Don't expect database security perfection either. You'll wear yourself out and tick off many of your users -- not to mention the trouble you'll have finding the budget to make everything happen.

    Work little by little. Small improvements in database security over time will put your organization exactly where it needs to be compliance-wise much sooner than you think. Start with one area such as system hardening (at both the database and operating system levels) or audit logging, and focus on that over the next few months. Once you fine-tune one area, move on to the next and literally go down the list of what needs to be in place for compliance with the broadest set of laws and regulations. If you focus on the highest level possible to meet all of your basic compliance needs, you'll get the most return on your time and money.

    A great way to boost your compliance efforts is to align your security practices with a widely accepted standard such as ITIL, COBIT and ISO/IEC 17799:2005.

    I usually recommend the ISO/IEC standard because it's what I've worked with the longest and I like how it clearly outlines all the essential
  • Consider these options when logging for security compliance in SQL Server

  • Take a look at this Top 10 list of SQL Server Security tips

  • information security areas. It's not database-, application- or operating system-specific, but it doesn't need to be. However, it'll be a great complement to your technical abilities on the database side.

    The 17799 components, like most others, can all be tied to database security in one way or another. The good thing is that none of the laws or regulations require you to use a specific information security standard; you're at liberty to choose which standard to use based on your organization's specific needs. You can even mix and match components from the different standards to come up with a custom information security framework.

    Do it the right way

    Before moving forward, you'll need to decide what's best for your organization. You may already have a compliance or an IT governance committee within your organization. If so, that's great -- you're well ahead of the curve. Work with them on adopting such standards to get your database security in line.

    I know, however, that security and compliance responsibilities often fall into the lap of the DBA and/or network admin, so you may be on your own. If this is the case, at least run what you're doing by management to get their buy-in and blessing so you'll have their support when you need it later. They are, after all, the people who are ultimately responsible for compliance.

    Whether you have a security committee or not, there's absolutely no point in recreating the wheel by developing your own database security standards. The good thing is you won't have to if you align what you're doing with a framework such as 17799. This will not only make you and your organization look like you're taking security seriously, but it will drastically reduce the effort it takes to get a good information security framework established. It will also help you meet the broadest number of compliance requirements without having to address the specifics of each law and regulation individually.

    After all, simplicity should be one of your top goals. If you keep it simple and work smart toward better security up front instead of winging it and assuming everything's going to be ok moving forward, you won't regret it.


    ABOUT THE AUTHOR:   
    Kevin Beaver Kevin Beaver is an independent information security consultant, speaker, and expert witness with Atlanta-based Principle Logic, LLC. He has more than 18 years of experience in IT and specializes in performing information security assessments revolving around compliance and IT governance. Kevin has authored/co-authored six books on information security including Hacking For Dummies and Hacking Wireless Networks For Dummies (Wiley) as well as The Practical Guide to HIPAA Privacy and Security Compliance (Auerbach). He's also the creator of the Security On Wheels audiobook series. Kevin can be reached at kbeaver ~at~ principlelogic.com.
    Copyright 2006 TechTarget


    Rate this Tip
    To rate tips, you must be a member of SearchSQLServer.com.
    Register now to start rating these tips. Log in if you are already a member.




    Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google


    RELATED CONTENT
    SQL Server security
    Can I encrypt and restore a database backup in SQL Server 2005?
    FAQ: How to troubleshoot and grant SQL Server permissions
    Secure SQL Server from SQL injection attacks
    How insiders hack SQL databases with free tools and a little luck
    Sarbanes-Oxley compliance checklist: IT security and SQL audits
    SQL Server source code analysis and management adds database security
    Ten common SQL Server security vulnerabilities you may be overlooking
    SQL Server 2008 security and compliance features reduce security risks
    Get your SQL Server security goals in order
    How secure is your SQL Server network design?

    SQL Server database design and modeling
    SQL Server database design disasters: How it all starts
    Physical data storage in SQL Server 2005 and 2008
    SQL Server 2008 data types: Datetime, string, user-defined and more
    Enforcing data integrity in a SQL Server database
    SQL Server and data manipulation in T-SQL
    Supertype and subtype tables in SQL Server
    SQL Server database design disasters: What not to do
    Check SQL Server database and log file size with this stored procedure
    SQL Server tempdb best practices increase performance
    FAQ: SQL Server databases how-to

    Database Administrator
    SQL Server database design disasters: How it all starts
    SQL Server database design disasters: What not to do
    How to create a SQL Server linked server to DB2
    Virtual database storage for SQL Server: Friend or foe?
    How to restore SQL Server database to transition server during upgrade
    Storage area network (SAN) basics every SQL Server DBA must know
    SQL Server backups using SAN database snapshots
    Sarbanes-Oxley compliance checklist: IT security and SQL audits
    SQL Server 2005 log shipping setup using the wizard
    Track changes to SQL Server 2000 and 2005 with one simple utility

    RELATED GLOSSARY TERMS
    Terms from Whatis.com − the technology online dictionary
    data corruption  (SearchSQLServer.com)
    data hiding  (SearchSQLServer.com)

    RELATED RESOURCES
    2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems
    Search Bitpipe.com for the latest white papers and business webcasts
    Whatis.com, the online computer dictionary

    DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.

    HomeNewsTopicsITKnowledge ExchangeTipsAsk the ExpertsMultimediaWhite PapersIT Downloads
    About Us  |  Contact Us  |  For Advertisers  |  For Business Partners  |  Site Index  |  RSS
    SEARCH 
    TechTarget provides enterprise IT professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective IT purchase decisions and managing their organizations' IT projects - with its network of technology-specific Web sites, events and magazines.

    TechTarget Corporate Web Site  |  Media Kits  |  Reprints  |  Site Map




    All Rights Reserved, Copyright 2005 - 2008, TechTarget | Read our Privacy Policy
      TechTarget - The IT Media ROI Experts