 |
|
| SQL Server Tips: |
|
|
|
DATABASE ADMINISTRATOR
Database security policies to think about
By Kevin Beaver, CISSP
01.08.2007
Rating: -3.75- (out of 5)
|
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 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
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.
|
|
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.
|
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.
|
|
|
|
|
|
|
|
|
|
| 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 . |
|
| | |
All Rights Reserved, , TechTarget |
|
|
|
|
|
