Database security policies to think about
With all the government and industry regulations affecting practically every business, sooner or
later, the time will come when you're essentially forced to put some information security policies
in place. You may already have the basic policies for passwords and data backups. But there's more.
So, if your organization is just now putting together its security policies or you've realized it
may be time to update a few things, there are several database security-related issues you'll need
to cover.
Technically, in order to determine exactly which security policies are needed, you need to
perform an information risk assessment. However, I understand that reality often dictates
otherwise. That said, I can think of few, if any, circumstances that wouldn't require the following
database-related
Premium Access
Register now for unlimited access to our premium content across our network of over 70 information Technology web sites.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy
Dig Deeper
-
People who read this also read...
-
This was first published in January 2007
security policies at the very least:
- Acceptable usage – what can/cannot be done on database servers such as web browsing and
installing/disabling malware and personal firewall protection as well as installation of MSDE, SQL
Server Express 2005, and other database software on non-server systems.
- Authentication controls – for databases as well as related applications and operating
systems including password requirements, multi-factor usage, etc..
- Business associates – dealing with external contractors, auditors, hosting providers,
etc. including contract provisions and service level agreements where applicable.
- Business continuity – disaster recovery and/or business continuity plan requirements to
help keep your databases up and accessible.
- Change management – documenting the who, why, when, how, and any related backout
procedures, etc..
- Data backup – what, when, and methods used.
- Data retention and destruction – what, why, methods used and timelines.
- Encryption – covering both data at rest such as encrypting specific rows, and data in
transit such as TLS between the database server and Web application. Data backups would also be
included.
- Information classification – labeling requirements for public, internal, confidential,
etc..
- Physical security – building, data center, and server security.
- Removal of property – servers, drives, tapes, and other property.
- Security testing and audits – what, how, when, and who will perform testing along with
what tools will be used.
- Separation of duties – the roles/responsibilities of users, DBAs, security auditors and
others involved with database management..
- System maintenance – patching, system purging/cleanups and malware updates.
- System monitoring and incident response – the who, why, when and how of real-time
monitoring and audit logging, as well as specific requirements for maintaining a formal incident
response plan.
- User authorization – adding/removing users and granting admin rights for whom, why, when
and for how long.
There are several critical points I want to make related to database-centric security policies.
First, if management hasn't declared their support (i.e. they're going to embrace and enforce the
policies), you might as well forgo this exercise
 |
| Get more on database security compliance here: |
|
|
|
|
|
|
altogether. So get them on board first. Second, scope your
policies at the highest level possible so you can maximize the number of departments and systems
covered. Maximize the number of regulations you can actually be in compliance with. In other words,
if you can help it, don't generate all of the above policies for your databases and have another
set for wireless networks, storage systems and so on. Likewise, understand your organization's
regulatory requirements at least to the point where one set of policies addresses PCI, GLBA, HIPAA,
SOX, etc. This will be best served if you have a compliance or IT governance committee that
oversees and implements security policies. You don't want your own set of policies to manage if you
can help it.
Finally, make sure you document your policies in a way that'll make comprehension and
administration as straightforward as possible. The following policy elements are essential for
keeping policies simple and manageable long term.
- Introduction – a brief overview of the topic such as encryption.
- Purpose – briefly outlines the high-level goal(s) and strategy of the policy.
- Scope – States which employees, departments and database systems are covered.
- Roles and responsibilities – outlines who's involved and what they're expected to do to
support the policy.
- Policy statement – your actual policy statement/statements. You should have one policy
statement per subject. In other words, create a separate template for each of the policies listed
above that you choose to use.
- Exceptions – underscores the people, departments, databases, etc. that are not covered
by the policy.
- Procedures – detailed steps on how the policy is being implemented and enforced in your
environment. You may want to reference this information and place it in a separate document.
- Compliance – outlines procedures on how compliance with this policy will be measured
including any metrics involved.
- Sanctions – outlines what happens when the policy is violated. This may include X
happens on the first offense, Y happens on the second offense, and Z happens on the third
offense.
- Review and evaluation – states when the policy must be reviewed for accuracy,
applicability, and compliance purposes (i.e. SOX, HIPAA, GLBA, PCI, etc.).
- References – Points to regulatory code sections and information security standards
(ISO/IEC 17799, ITIL, COBIT, etc.).
- Related documents – points to other policies, guidelines, standards, and related
documents.
- Revisions – section for documenting ongoing changes made to this policy document.
- Notes – highlights notes, tips, etc. that can help with future policy management and
enforcement.
If you do all of this to build out your policies the right way, it'll save you a lot of time and
headaches over the long haul and make your auditors happy to boot. Not a bad payoff for a few days
worth of work.
ABOUT THE AUTHOR:
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 2007 TechTarget
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.
Join the conversationComment
Share
Comments
Results
Contribute to the conversation