You are on page 1of 3

DATABASE SECURITY

PLANNING CHECKLIST

OVERVIEW

The purpose of this enterprise information security checklist is to help information technology (IT) managers and administrators identify and address the issues and tasks they face in protecting information stored in databases. The checklist treats other security issues, such as the confidentiality of network communications, to the degree they play a role in protecting this information.

The checklist contains two elements, the first of which is a series of checkboxes and text boxes covering an enterprise’s specific business and technical characteristics. The process of filling out these boxes

helps to clarify an enterprise’s specific security issues and creates a quick reference for tracking progress. The second element consists of suggestions, observations, and resource materials related to the checkbox topic areas.

Protecting sensitive information is an ongoing task that requires coor- dinated effort throughout an enterprise. Use this checklist as part of a comprehensive information security process.

INFORMATION

Select the types of information that are stored and processed within your enterprise’s databases. Include databases that are part of other enterprise applications, such as customer relationship management (CRM) and enterprise resource planning (ERP).

Enterprise Financial Enterprise Proprietary Enterprise Trade Secret Personal Financial Personal Medical Credit Card Public Safety Other:

Other:

External regulations and standards define the security measures required to protect some types of information. Examples include:

Government legislation - Gramm-Leach-Bliley Act (US), Financial information:

http://www.complianceheadquarters.com/Privacy/66FR8615.txt

  • - Health Information Portability and Accountability Act (US), Medical information: http://www.cms.hhs.gov/regulations/hipaa/cms0003- 5/0049f-econ-ofr-2-12-03.pdf

  • - 95/46/EC Directive on Data Privacy (EU), General personal information:

http://europa.eu.int/smartapi/cgi/sga_doc?smartapi!celexapi!

prod!CELEXnumdoc&lg=EN&numdoc=31995L0046&model=guichett

  • - Australia’s Privacy Act, General personal information: http://www.privacy.gov.au/act/index.html

Credit card standards:

  • - The American Express Merchant Services Data Security Standards: http://home5.americanexpress.com/merchant/resources/fraudprevention/ datasecurity.asp

  • - The MasterCard Site Data Protection Service™: http://sdp.mastercardintl.com/cgi-bin/mainpage.cgi

  • - The VISA U.S.A. Cardholder Information Security Program (CISP): http://usa.visa.com/business/merchants/cisp_index.html

The security technologies, policies, and procedures defined by these regulations and standards apply equally to the protection of an enterprise’s own sensitive information.

THREATS

Select the types of threats to your enterprise and its information that you are concerned about.

Competitors Current Employees Contractors/Consultants Former Employees Customers Partner companies Governments Professional Hackers Other:

Assess each identified threat in terms of Opportunity Resources Determination Skill

Use these assessments when selecting security technologies. For example:

A disgruntled employee may try to use her legitimate access permissions to steal from her company. This threat speaks to the importance of strong database access controls and auditing.

A more determined adversary may go so far as becoming an employee at a target enterprise, preferably as an IT administrator. This threat underscores the importance of auditing administrator activities and limiting their access to information.

The goal is to ensure the degree (and cost) of protection corresponds to

the risk poised by these threats.

Parenty Consulting, LLC

information security and privacy

DATABASE SECURITY

CHECKLIST

CONTINUED

USERS

Select all of the types of users who have access to information stored in your databases.

Employees Contractors/Consultants Customers Business partners Regulators Other:

Think of users in the broad sense of anyone who can directly access information in a database.

Keep each type of user in mind when filling out the rest of the form.

Assess the business benefit to an enterprise that results from providing access to each type of user in light of the increased risk the users pose.

USER AUTHENTICATION

Select the means your enterprise currently uses or plans on using to authenticate users.

Password PIN Token (one-time password) Digital certificate Smart card Biometric Other:

When selecting authentication evidence, consider:

The type of user and the sensitivity of the information they can access. For example, an enterprise could use Kerberos for authenticating its employees and passwords for customers.

Hardware requirements. Smart card and biometric-based authenti- cation require special hardware readers that are not currently widely available. This limits their practical use for large user populations outside of an enterprise’s direct control, for example customers. One-time password tokens do not have this limitation.

Passwords remain the most common form of user authentication so enforce a sound password policy including, among other things:

Minimum password length Password aging Locking accounts after a number of failed login attempts Hard to guess passwords

Routinely test password strength with tools such as:

John the Ripper for UNIX: www.openwall.com/john/ LC4 for Windows: www.atstake.com/research/lc/

Disable all of a user’s accounts as soon as he no longer has a busi- ness need for them, such as when an employee leaves a company.

Periodically review all user accounts to make sure that they belong to legitimate users and not to past employees or contractors, for example.

NETWORK ACCESS

Select the types of current or planned network access to your databases.

Internal corporate network (your own) Other corporate network (not your own, e.g., partners’ or customers’) Dial-up Wireless Home DSL, cable modem, etc Hotel room high speed Internet connection Public computers: hotel business centers, airport kiosks, cyber cafes, etc. Other:

All of the network options listed above leave information vulnerable to disclosure, modification and/or redirection. For example:

Ethernet LANs are vulnerable to promiscuous mode computers:

www.stanford.edu/group/itss-ccs/security/unix/promisc.html Switched LANs are vulnerable to ARP Cache Poisoning:

www.sans.org/rr/threats/address.php

Enterprise Network Encryption Options: Use a combination, as appropriate. Option 1: Virtual Private Network (VPN) Encrypts all Internet traffic, eliminating need for application- based encryption (+) Not cost-effective for large, external user populations, e.g. customers (-) No encryption within enterprise, internal network (-) Option 2: Per Application (DBMS) Encryption

Protects complete network connection from database to user (+)

Application must support network encryption (-)

Still need to protect client computers through personal firewalls, for example.

Parenty Consulting, LLC

information security and privacy

DATABASE SECURITY

CHECKLIST

CONTINUED

INFORMATION ACCESS

Select and list general access control policies that are important for your enterprise.

Access privileges are based a user’s organization. Access privileges are based a user’s business function (job). Ethical Walls separate different business functions. Administrators should not have access to all operational data. Access privileges vary according to application. Other:

Other:

Access controls should be an integral part of a DBMS because:

They can’t be bypassed. If an application enforces access control decisions, an attacker can use an alternate application or ad hoc query tool to retrieve information. They are more flexible. Changing access controls within a DBMS don’t require rewriting applications.

They reduce risk. Only the mistakes (or malice) of the DBMS

administrators who configure access controls can introduce

vulnerabilities. Otherwise, every application developer is a potential threat.

HIGHLY SENSITIVE INFORMATION

List several types of information whose disclosure could result in significant harm to your enterprise or to others.

1.

2.

3.

4.

5.

6.

Encrypting highly sensitive information while it is stored within a database provides an added degree of protection in the event that other security measures fail or don’t exist as can happen with cyber attacks, physical theft, and unethical administrators.

Protect encryption keys. Encrypted information will only be safe if the keys used to encrypt it are safe. Don’t leave keys vulnerable to the same attacks as your information.

Keep performance in mind when applying encryption to a new or existing database. Avoid, for example, encrypting columns containing database keys.

Use initialization vectors when encrypting information, such as test results, that can only assume a small number of possible values. This protects against inference and statistical attacks because each encrypted value will be different.

AUDITING

Select the types of activity you want to record. Attempts to bypass security protections, e.g. denied access requests Other security events, e.g., logon, logoff, administrator operations User actions for accountability and/or regulatory compliance Other:

Configure database auditing features to collect the audit records needed to meet these objectives.

Enforce technical and procedural measures to protect the integrity (and in most cases the confidentiality) of audit infor- mation and maintain a "chain of custody" to ensure the audit records can be used for the stated business objectives.

Identify the business objectives for auditing. These can include:

Detecting and stopping attackers Detecting insider abuse Prosecuting attackers and insiders Resolving customer disputes Litigating customer disputes Incident damage assessment

To review this checklist with a Sybase Professional, please call 1-800-8-SYBASE.

This database security planning checklist has been licenced by Sybase for use with all Sybase products. Copyright © 2003 Parenty Consulting, LLC. Unpublished rights reserved under U.S. copyright laws. Sybase, the Sybase logo, and Adaptive Server Enterprise are trademarks of Sybase, Inc. All other trademarks are property of their respective owners. ® indicates registration in the United States. Specifications are subject to change without notice. MIL 5617