To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 1

Database MSB

Typically when most folks discuss effective “cyber hygiene” they frequently ask “where’s the beef?” That

is, what are the essential security requirements and then harmonized within what context and framework

to help set priorities? (Hint – use a “MSB”) Since many organization have separate IT/Operations and

Security departments, there needs to be a more formal communications method to establish concurrence

on a common, risk based, security strategy approach. In that regard, this paper proposes a Minimum

Security Baseline (MSB) approach for storage area networks (SANS) / databases (DB), along with

associated DB management (DM) aspects to establish an effective cyber security posture and protections

methods; thus provide an effective, value-added, minimal residual risk DB / SANS environment.

Summary – Ineffective IT and security device setup and patching are the root cause of the vast majority

of security vulnerabilities. These self-imposed threat vectors are the leading cause of security incidents

which are the predominate method for hackers to install malware and take advantage of system

weaknesses, leading to stolen data and resources. Maintaining the system ‘hygiene’ (patches, device

settings, access controls, etc) is the key proactive defense to minimize these vulnerabilities. The typical

method to minimize hygiene vulnerabilities is to have an effective IT asset management (ITAM) /

configuration management DB (CMDB) approach with the key configuration items (CIs) identified,

tracked and managed. These CIs need to be managed within an accepted best industry practices

operational environment. This paper provides a background in data security sources, examples of industry

accepted practices, and recommendations on the major DB CIs within the MSB to enable effective data

security and minimize the enterprise’s risk management posture.

Background – A MSB addresses an information security configuration standard, sometimes referred to

as an organization’s internal “best practices.” The MSB is predicated on having a well-known, approved

security architecture with requisite device standards and system specifications addressed therein. MSBs

can be applied to many areas within an organization, including routers, switches, firewalls, servers, and

all major security products. The MSB configuration standards should detail the key controls such as

security patch minimums, unnecessary services to disable, hardening of products, etc.

Any database security effort is necessarily complex, as there are many variables to consider, many of

those are in the aggregate critical. Yet deciding on what the most essential database security CIs are is

tough, whereas where to draw the line on what is most valuable to track is not always clear. This paper

proposes the essential DB CIs within a MSB, but does not cover the basics of database security, nor the

specific installation and sustainment processes, there are many sources for that perspective, including:

https://docs.oracle.com/cd/B19306_01/server.102/b14220/security.htm

http://www.db-security.org/report/dbsc_guideline_ver2.0_e.pdf

This paper does offer the highlights of DB protection, best / industry practices, authoritative sources of

DB / data protection and security information and guidance, and most importantly the key DB CIs to use

in any Security and ITAM / CMDB processes. The following sections cover several elements to help

frame and define how to develop a DB MSB and the associated CM and security processes therein. This

high level relationship is illustrated below.

As a “reader / admin note” - we heavily leverage the documents listed in the paper and references section,

liberally excerpting key points and steps from these authoritative sources, versus restating their sage

guidance in other terms. If / when we formally publish this MSB, the proper attribution will be added to

all - for this first MSB approach article, we’re sharing the approach, key sources and our list of DB CIs.

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 2

Database security concerns the use of a broad range of information security controls to protect databases

(potentially including the data, the database applications or stored functions, the database systems, the

database servers and the associated network links) against compromises of their confidentiality, integrity

and availability. All security involves managing various types or categories of controls, such as technical,

procedural/administrative and physical; whereas database security is in a broad realm of computer and

information security as well as privacy protections and risk management.

Overall security risks to database systems include (but are not limited to):

Unauthorized or unintended activity or misuse by authorized database users, database

administrators, or network/systems managers, or by unauthorized users or hackers (e.g.

inappropriate access to sensitive data, metadata or functions within databases, or inappropriate

changes to the database programs, structures or security configurations);

Malware infections causing incidents such as unauthorized access, leakage or disclosure of

personal or proprietary data, deletion of or damage to the data or programs, interruption or denial

of authorized access to the database, attacks on other systems and the unanticipated failure of

database services;

Overloads, performance constraints and capacity issues resulting in the inability of authorized

users to use databases as intended;

Physical damage to database servers caused by computer room fires or floods, overheating,

lightning, accidental liquid spills, static discharge, electronic breakdowns/equipment failures and

obsolescence;

Design flaws and programming bugs in databases and the associated programs and systems,

creating various security vulnerabilities (e.g. unauthorized privilege escalation), data

loss/corruption, performance degradation etc.;

Data corruption and/or loss caused by the entry of invalid data or commands, mistakes in

database or system administration processes, sabotage/criminal damage etc.

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 3

It’s instructional to start a DB MSB discussion with the key DB vulnerabilities and threats; thus better

understand the accepted industry practices to minimize those risks, and better manage related CIs to

ensure the systems, programs and processes are effectively maintained.

---Top ten 2015 Database Vulnerabilities:

• Excessive and Unused Privileges

• Privilege Abuse / Elevation

• Input (SQL) Injection

• Malware / DB platform vulnerabilities

• Weak Audit Trail

• Storage Media Exposure (primary and backup)

• Exploitation of Vulnerabilities (and Misconfigured Databases)

• Unmanaged Sensitive Data

• Denial of Service

• Limited Security Expertise and Education

http://www.imperva.com/docs/wp_topten_database_threats.pdf

---External Threats:

• Web application attacks (SQL-injection)

• Insider mistakes

• Weak or non-existent audit controls

• Social engineering

By addressing these top threats, organizations can better address global compliance requirements and

industry best practices related to data protection and risk mitigation.

The security, privacy and protection of database assets are an increasingly mission essential function to all

organizations, especially minimizing data breach risks from DB vulnerabilities or lack of effective

encryption. To that end, the Company Database should provide a rich set of security features and controls

that can be used to implement a comprehensive data security strategy. The features ensure that users can

access only the database objects for which they have been authorized. Security controls make sure that all

sensitive data is fully protected and access to it is effectively audited and monitored. The main DB

security capabilities fall under four categories that are needed for effective risk management:

authentication, authorization, data security and auditing / monitoring (details in the appendix).

The database categories discussed therein are then best instantiated within common data security practices

and processes. Several DB security best practices are provided next to provide a framework for an overall

suggested, common process to maintain a secure DB. This standard process, set of security principles,

then provides the perspectives to distill the key DB CIs needed for effective data security into a MSB;

whereas the Key security tenets are:

1. Install Only What Is Required

2. Lock and Expire Default User Accounts

3. Change Default Passwords

3a. Change default passwords of administrative users

3b. Change default passwords of all users

3c. Enforce password management

4. Enable Data Dictionary Protection

5. Practice Principle of Least Privilege

5a. Grant necessary privileges only

5b. Revoke unnecessary privileges from PUBLIC

5c. Restrict permissions on run-time facilities

6. Enforce Access Controls Effectively

6a. Authenticate clients properly

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 4

6b. Limit the number of operating system users

7. Restrict Network Access

7a. Utilize a firewall

7b. Never open a hole through a firewall

7c. Prevent unauthorized administration of the Oracle Listener

7d. Check network IP addresses

7e. Encrypt network traffic

7f. Harden the operating system

8. Apply All Security Patches and Workarounds

Next we list a couple of DB security best practices, where the details are provided in the appendix.

Database Security Best Practices

http://www.applicure.com/blog/database-security-best-practice

Database Security to Reduce Data Breach impacts - which are exceedingly costly (notification costs,

fines, etc) and very damaging to organizations (reputations, loss of business, etc).

https://datasafestorage.wordpress.com/2011/11/15/beating-the-breach-10-best-practices-for-database-

security-and-compliance/

In today’s interconnected world, the boundaries of our business infrastructure are constantly being

extended by the emergence of cloud, mobility, big data and more. To be useful, a company’s data must be

continuously connected to its customers, partners and employees. That exposes sensitive data to more

automated and targeted attacks than ever before. We’re now seeing numerous attacks that easily bypass

traditional perimeter defenses by exploiting Web application vulnerabilities such as SQL injection, or by

spear phishing key employees and then using stolen credentials to compromise back-end databases.

Despite more attention being paid to secure coding practices, SQL injection continues to be the #1 high-

volume signature and a favorite attack vector amongst malicious groups (see appendix for methods to

minimize this threat). Lowering compliance costs by streamlining processes is also an important driver

for implementing database security technologies. Many organizations are now looking to replace their

manual, siloed compliance processes with a single unified set of centralized, standardized and automated

controls for all key applications, database platforms and compliance mandates.

NOTE - For added best industry practices and additional data security information, see the appendix.

Discussion - The previous DB security information provided (and additional background in the appendix)

can be overwhelming with the complex interactions of many factors, access control, encryption, etc. To

start this section, we propose five ‘getting started’ activities, followed by several mandatory security

standards for most systems, ending with recommended security practices to invoke. Following that,

hardening is briefly covered, then a list of proposed DB MSB CIs is suggested, to then collaborate with

IT/OPS DB team to finalize what to monitor and track in the Department’s ITAM / CMDB process.

Getting started key Tasks:

1. Manage Usernames and passwords

Oracle and other databases come with built-in default usernames and passwords—several hundreds of

them—created to make it easier to set up the system. These should be erased after the system has been set

up. There are free tools available for Oracle that do that: http://www.petefinnigan.com

2. Remove unnecessary components

DM systems with their multitude of components creates a very large attack surface and thus more

opportunities to infiltrate the database. Thus conduct a periodic review the database configuration and

remove components—including various extensions and add-ons— that users are not using.

3. Apply security patches

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 5

New database vulnerabilities are uncovered constantly and many are patched by the database vendors

themselves, who issue updates and patches to the DBMS. It is not always easy to apply those patches,

because they require testing and database downtime. But even deciding on a schedule where patches are

applied twice a year is better than not applying them at all.

4. Secure coding practices (bind variables)

Many database vulnerabilities are exposed due to the way applications are coded and their interaction

with the database. Lack of accountability and lack of secure coding practices may open the floodgates to

breaches and attacks. For example, SQL injections in web applications can be thwarted entirely by

binding variables in SQL statements. Unfortunately, many developers still do not use the bind variables

method when developing applications, nor use an effective code review tool set, thus leaving the database

exposed to SQL injections. (see appendix for more details)

5. Monitor, audit, monitor, and audit again

You cannot protect an asset if you can’t see it or don’t know that it even exists. This seems obvious, and

yet most database administrators and security professionals have no idea of the exact number, location,

data sensitivity, and security posture of each and every database that exists within the environment.

Mandatory Security Standards for All Systems:

---General

All multi-user, business critical or restricted databases must be inventoried at the appropriate

level. Additionally, some description of database contents is required; detailed descriptions will

be required when the database contains financial information

Servers and host systems on database and application hosts must be configured and administered

using current standards including the Windows Server Administration and Security Standards

Physically secure database servers and their backup media in locked, access-controlled rooms,

through cable locks, cabinets or other similar controls

Disable services or features of the operating system and database server that are not in use

Make sure that all data and system files are installed on appropriate partitions and that the

appropriate ACLs are applied. If someone should gain access to the OS, make sure that the

necessary permissions are assigned

Never permit user applications to send arbitrary SQL commands to the server without the

application serving as an intermediary, and never permit public Internet-accessible applications

(such as web applications running on IIS) to send user-defined SQL commands to the back-end

database, even with input validation rules

Database should be installed under an administrative account

Document all data interfaces, including applications, databases and messaging links

All default and null passwords should be changed to passwords compliant with the MISP policy

---Access Control

Administrative access must be individual user accounts and not a shared group account

Neither user nor administrator credentials may be transmitted in clear text. Consider using

SSL for encrypting application traffic between clients and database servers or using IPSec for

encrypting communications with the server

Assign a long and complex password to administrative accounts (OR use 2-factor authentication!)

In systems where users are directly accessing the database server using either client utilities or an

application, directory services should be used. Using Active Directory will automatically enforce

password aging and strength rules

Delegate authority over the server and its databases by utilizing fixed server and database roles

appropriately, or by creating own custom roles, so that excessive power is not being placed in the

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 6

hands of those who don't need it. In short, do not simply place everyone in the administrator role

out of convenience. Also avoid granting rights to individual accounts rather than groups.

All database and server management scripts must be stored in an access-controlled folder or

directory. Audit all access. Scripts should not contain hard-coded passwords. Service OS

accounts should not allow a direct login

---Monitoring

Regularly audit all shared folders on the database server to ensure that all permissions are

minimal and that none of the shares are unnecessary. Be especially wary of shared folders that

permit Write access.

Regularly audit the membership of the administrator role and the passwords of all accounts and

logins in it.

Document grants of elevated database permissions.

--- Highly restricted environment, review the security controls listed in the appendix

Key Oracle DB security items to manage (from which a list of CIs is distilled and documented in this

section, all of which is must be agreed to by both IT/OPS & SEC) (see appendix for expanded details):

--- install only what is required

--- lock and expire default user accounts

--- changing default user passwords

--- change passwords for administrative accounts

--- change default passwords for all users

--- enforce password management

--- secure batch jobs

--- manage access to SYSDBA and SYSOPER roles

--- enable oracle data dictionary protection

--- follow the principle of least privilege

--- manage / restrict PUBLIC privileges

--- restrict permissions on run-time facilities

--- authenticate clients

--- restrict operating system access

--- secure the Oracle LISTENER

--- secure external procedures (EXTORIC agent, etc)

--- checking network IP addresses

--- harden the operating system

--- encrypt network traffic

--- apply all security patches (OTN & Metalink)

Database standards. Besides getting the database security ‘right’ and specifications related therein, it’s

essential to have a common set of standards to frame and align the data security / risk management to.

(NOTE - A standards search tool to consider: https://www.itu.int/ITU-T/security/main_table.aspx )

(A DISA STIG ‘requirements’ viewer is here (most best practices is to account for “High & Med

findings): https://www.stigviewer.com/stig/database_security_requirements_guide/ )

The key basis of our DB MSB references and sources will be an Oracle’s Database Security Checklist (by

ISACA) - based on Oracle’s extensive security guides, listed below, for reference, but not covered herein.

https://docs.oracle.com/cd/E11882_01/network.112/e36292.pdf (11.2 – 448 pages)

https://docs.oracle.com/database/121/DBSEG/E48135-13.pdf (12.1 – 840 pages)

The security checklist reference is from ISACA, link below, key excerpts therein are:

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 7

http://www.isaca.org/groups/professional-english/oracle-database/groupdocuments/twp-security-

checklist-database-1-132870.pdf (as complemented by:

http://www.oracle.com/technetwork/database/security/security-compliance-wp-12c-1896112.pdf )

Database hardening. Once the database has been verified to be ‘acceptably secure’ (a significant effort

by itself conducting CM, V&V, etc, as discussed earlier), then the next phase would be to ‘harden’ the

database, providing added security measures. Since this is a MSB (minimum security baseline),

hardening is beyond the scope, whereas two sources are listed below to facilitate that key data protection

hardening aspect when the time is appropriate.

https://security.berkeley.edu/resources/best-practices-how-articles/database-hardening-best-practices

http://www.mcafee.com/us/resources/white-papers/wp-hardening-database-security.pdf

*** Specific DB/SANS MSB CIs:

This section distill the previous recommendations and guidelines into a set of set-up checks to verify the

baseline and then items to periodically assess as part of an ITAM/CMDB process. Also see appendix item

#4 for Oracle steps details and #8 for more DB security suggestions, implementation specifics, as well as

suggested key references, especially the very detailed Oracle security guides listed above.

---SET-UP (do once / occasionally): (note – specific Oracle feedback in blue text)

---Secure the operating system in accordance with the Oracle Linux Security Guide

---Project Lockdown is a structured approach to securing Oracle database infrastructure.

A – Assess capabilities installed, delete those not needed, and remove sample schemas.

B – As needed, lock and expire DEFAULT user accounts (note: DBCA automatically locks and expires

most default database user accounts on install)

Create individual accounts for each DBA (and assign DBA role). Lock SYSTEM. Deny DBA accounts

read-access (no SELECT) on underlying data.

C – Verify the same password is not used for administrative accounts (such as such as SYSTEM,

SYSMAN and DBSNMP)

D – Use the installation option to pre-configure a default profile enforcing password complexity,

expiration and reuse.

E – Verify and secure batch jobs – using the Secure External Password Store feature to manage

permissions in the Oracle “Wallet” containing the username and password be set accordingly as anyone

with access to the Wallet could use it to authenticate to the database.

F - Manage access to SYSDBA and SYSOPER roles – create separate admin accounts. Restrict

connecting with the SYSDBA role except when absolutely required.

Audit all SYS operations with AUDIT_SYS_OPERATIONS=TRUE

G - Implement data dictionary protection to prevent users who have the "ANY" system privileges from

using such privileges to modify or harm the Oracle data dictionary.

H – Set up and restrict PUBLIC privileges – use the granular authorizations for PL/SQL network utility

packages granted to PUBLIC.

Evaluate which SYSTEM privileges are granted to PUBLIC (SELECT ANY SEQUENCE for example)

and remove those not required by your application. Oracle Support Notes for PUBLIC privileges include:

Be Cautious When Revoking Privileges Granted to PUBLIC (Doc ID 247093.1)

Invalid Components, Objects After Revoke Public Privileges (Doc ID 1577002.1)

Can we Revoke Execute dbms_random from public/dbms_job from public/ Package From Public

(Doc ID 2195199.1)

Problems After Revoking Execute On DBMS_SQL, DBMS_JOB, DBMS_LOB,

DBMS_RANDOM, and DBMS_OBFUSCATION_TOOLKIT From PUBLIC (Doc ID

1165830.1)

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 8

Revoking Privileges on SYS Package From PUBLIC Errors Out with ORA-1927 (Doc ID

471863.1)

PUBLIC : Is it a User, a Role, a User Group, a Privilege ? (Doc ID 234551.1)

I - Restrict permissions on run-time facilities. When granting permissions on run-time facilities (e.g., the

Oracle Java Virtual Machine (OJVM)), grant permissions to the explicit or actual document root file path.

J - Authenticate clients. Verify database initialization parameter REMOTE_OS_AUTHENT is FALSE.

K - Restrict operating system access. Limit the number of users with operating system access on the

Oracle DB host. Restrict the ability to modify the default file and directory permissions for the Oracle DB

home (installation) directory or its contents. Restrict usage of symbolic links on the operating system.

Create individual accounts for those requiring operating system access. The OS can be audited

too. Do not allow anybody to log in to the oracle account; this takes away ‘ / as sysdba ‘

Create operating system account ‘mike’ with $ORACLE_HOME/bin in his PATH and then

create database account ‘mike_dba’ (with DBA role). Audit ‘mike’ at OS level and audit

‘mike_dba’ at database level.

L - Secure the oracle listener. Oracle Database uses local OS authentication as the default authentication

mode. This mode requires the Oracle Net administrator to be a member of the local DBA group. Setting a

password for the TNS listener in Oracle Database simplifies local administration. Ensure the

ADMIN_RESTRICTIONS_LISTENER is ON (default)

Oracle Database Listener Security Guide has good insights. An updated version maybe available.

M – Ensure a firewall is used and configured properly

Consider a database-specific firewall that can not only alert on and/or reject SQL-injections but also

provide a audit function as well as enforcing a trusted path to the database server.

N - Use the Oracle Net valid note checking security feature to allow or deny access to Oracle server

processes from network clients with specified IP address.

O - Encrypt network traffic between clients, databases and application servers

Encrypt Oracle Net (sqlnet in the old vernacular) between database and Application Servers as well as

Integrated Development Environments (Toad, SQLDeveloper, etc.). Also configure SSL between

desktops and Application Servers. No ‘data in motion’ should be unencrypted; even on your intranet.

P - Choose either domain authentication or database authentication for DB users, do not mingle them.

Q – Provide a clear description and process for establishing roles and groups.

R – Separate / segregate DB admin duties

---PERIODIC CHECKS:

1 – Check for default passwords (by using the database view DBA_USERS_WITH_DEF_PWD)

2 – Status check of password management (e.g.; Enforce failed login, password expiration, password

complexity and reuse policies using the Oracle profile)

3 – Periodic audit and monitor all activities of users connecting with the SYSDBA role or other

administrative roles such as the DBA role, CREATE ANY TABLE privilege and so forth.

4 – Apply all critical / severe rated security patches. Periodically check the Oracle Technology Network

(OTN) security site http://www.oracle.com/technetwork/topics/security/alerts-086861.html Also check

Oracle Worldwide Supports services site, Metalink (registration needed); http://metalink.oracle.com.

5 – Periodically review the DB logs / audit data for abnormalities / potential threats.

6 – Periodically assess the DB configuration (software, modules / services, etc)

7 – Periodically assess the DB / OS / platform interaction (extended stored procedures, admin rights,

block adhoc connections, set DB port numbers to non-default values, etc)

The Database Security Risk Assessment (DBSRA) scripts can be run periodically to keep an eye on

database vulnerabilities.

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 9

Recommendations -

--- Establish a data security WG, initially internal to IMS, to manage the technical requirements and

choices, thresholds therein, as well as provide some level of governance throughout.

--- Conduct the set-up steps and document baseline – quantify specific CIs to track.

--- Using the best practices in appendix, set up MySQL best practices and adjust MSB (where needed)

--- Set up a standard operating process (SoP) to conduct the periodic checks (use ITAM / CMDB process)

--- Query users / business owners on key DB concerns, integrate into the set-up or periodic checks…

References / bibliography:

CIS oracle 11gR2 Benchmark and checklist

https://web.nvd.nist.gov/view/ncp/repository/checklistDetail?id=567

https://web.nvd.nist.gov/view/ncp/repository/checklistDetail?id=628

https://benchmarks.cisecurity.org/tools2/oracle/CIS_Oracle_11g_Benchmark_v1.0.1.pdf

NIST NVD oracle 11.2 DB STIG

https://web.nvd.nist.gov/view/ncp/repository/checklistDetail?id=512

Oracle Security recommendations

https://docs.oracle.com/cd/B19306_01/network.102/b14266/checklis.htm#i1010098

http://www.cgisecurity.com/database/oracle/pdf/9i_checklist.pdf

https://www.dbdr.com/wp-

content/uploads/2013/11/NWOUG_2013_How_to_Protect_your_Oracle_Database_from_Hackers.pdf

http://www.oracle.com/technetwork/database/security/security-compliance-wp-12c-1896112.pdf

Overview brief on Securing Oracle

https://www.integrigy.com/files/Integrigy%20Security%20Myths%20and%20the%20Oracle%20Databas

e.pdf

AN oracle reference list of references.

http://www.isaca.org/Groups/Professional-English/oracle-

database/GroupDocuments/Sources_of_Assurance_for_an_Oracle_Database_Update_5.pdf

Overall DB data security and CM sources

http://www.sans.org/reading-room/whitepapers/analyst/secure-configuration-management-demystified-

35205

https://www.giac.org/paper/gsec/170/develop-companys-first-security-baseline-standard/100648

http://www.cdse.edu/documents/toolkits-issm/ODAA_Baseline_Security_Config.pdf

DB STIGs

http://iase.disa.mil/stigs/app-security/database/Pages/index.aspx

https://wateroxconsulting.com/archives/dod-stigs-database-security-requirements-guide/

NIST checklists repository

https://web.nvd.nist.gov/view/ncp/repository

Database sources

https://www.sans.org/reading-room/whitepapers/analyst/oracle-database-security-secure-34885

http://www.dbspecialists.com/files/presentations/Thirteen_Ways_to_Make_Your_Oracle_Database_More

_Secure.pdf

STIG (viewer) for Oracle 11.2

https://www.stigviewer.com/stig/oracle_database_11.2g/

SQL server Security

http://sqlblog.de/blog/2009/08/sql-server-security-check-list/

Database hardening best practices

https://security.berkeley.edu/resources/best-practices-how-articles/database-hardening-best-practices

http://sqlmag.com/database-security/hardening-sql-server

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 10

Appendix: (added background, technical details, errata, etc)

(1) MySQL best practices

There are several sources to use, many are the same as the oracle / overall items listed earlier. Follow on

task will be to capture the key items from these source and develop a SET-UP and PERODICS CHECKS

aspects as done earlier.

http://www.databasejournal.com/features/mysql/article.php/3918631/Top-10-MySQL-Best-Practices.htm

http://www.hexatier.com/mysql-database-security-best-practices/

http://www.yassl.com/files/yassl_securing_mysql.pdf

(2) The main DB security capabilities fall under four categories that are needed for effective risk

management: authentication, authorization, data security and auditing / monitoring (each briefly

described below).

Authentication

Authentication allows the database to securely verify a user’s identity before allowing any access to

database objects. A fundamental security best practice is to ensure that all users are uniquely identified

and authenticated using strongly constructed credentials. The Company Database should provide options

for both internal and external authentication of users. Passwords for logging into the database must use a

combination of alpha, numeric and special characters. Security features in the database are integrated with

corporate lightweight directory access protocol or Kerberos-based authentication systems. This allows for

the centralized management of database users to be consistent with the management of users for other

systems and applications within an enterprise.

In addition, the Trusted Sessions feature in the database is used to assert end-user identities and roles

through middle-tier, application-pooled connections. These identities can then be used for access rights

and checking and auditing queries submitted by the middle tier on behalf of an end user.

If used, Company Wallet / password managers can be employed to securely store and protect passwords.

This eliminates the need to store passwords in clear text in scripts.

The database can also enforce IP filters to lock down privileged user accounts to only the applications,

load/export systems and backup/archive operations for which the accounts have been authorized. This

process AND using a firewall provides additional protection in the event an account is compromised.

Authorization

The “principle of least privilege” requires that a user be granted the minimum level of access required for

his or her job. The Company Database should support a discretionary access control policy that is

implemented with an extensive, granular set of rights and privileges that allows users to be given only the

access needed to perform specific operations on particular database objects. Proper management of these

rights is critical to prevent unauthorized or inappropriate access. The Company Database handles this by

using security roles to authorize database access rights by application, job description or responsibility.

After effective roles and responsibilities are established, focusing on the authorization process can

significantly reduce the complexity and cost of security administration in large database environments

and also allows for security management at a level that closely corresponds to an organization’s structure.

Row- and column-level controls are used by the database to further restrict access to selected information

in database tables. Column-level security restricts access to specific columns, while row-level security

filters access to rows based on the identity of the user submitting queries.

Using Multiple Layers of Security / Defense in depth and breadth is a well proven strategy that involves

implementing multiple layers of security defense mechanisms to protect critical business data. If a single

layer or mechanism fails or is compromised, other layers ensure the security of the data. The security

layers take multiple forms. Some include a company’s security policies and standards, others include the

procedures to manage and monitor system access, while still others are implemented as technological

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 11

controls. It is important to recognize that there is no one layer or set of controls that can be implemented

to fully and properly secure a database system. Our company IdAM approach covers most aspects of

Microsoft’s Active Directory, etc, as well as DBs.

Data Security

Sensitive information can be vulnerable when transmitted over non-secure networks or where appropriate

access controls have not been enabled. Moreover, compliance with some standards and regulations

requires encryption to secure the data during transmission and when it’s stored. The Company Database

should support strong encryption through industry-standard cryptographic algorithms and securely

generated encryption keys. Network traffic encryption protects the confidentiality of sensitive

information when it’s transmitted over any public or untrusted network. It also protects the data from

being compromised by network “sniffers.”

The database also lets organizations employ column-level encryption or tokenization to secure

information stored in tables. This helps protect sensitive data from both internal and external threats,

including being compromised by privileged database users. Disk and tape archives containing sensitive

information can be encrypted before they are transferred to an offsite or commercial storage facility. This

removes the possibility of the data being at risk if the archives are lost, stolen or misplaced. See DB

encryption suggestions at the end of this appendix.

Auditing and Monitoring

The Company Database audit logging facilities should assess different kinds of security events to detect

possible security violations, such as attempts to compromise a user’s login, unauthorized attempts to

access database objects or changes to the logging rules. Access log rules can be configured to audit all

access to sensitive data and all operations performed by privileged database users.

A security administrator can configure the system to log any combination of access requests, requests

denied or specific types of requests for any or all users. The log records can include the SQL expression

that was used to perform the access, whether indirectly through views or directly to base tables.

Companies can use database features to regularly monitor all audit logs. This helps ensure that users are

performing only activities for which they have been explicitly authorized. The frequency of reviews

should be determined by risk factors such as the criticality of the database to business operations, the

value or sensitivity of the information stored in the database, past issues with system compromises or

misuse of information and the extent to which the system might be accessible via non-secure networks.

The database gives organizations the ability to periodically archive all audit logs for use in security

investigations or forensic analysis. If a breach is detected, the availability of the audit logs is critical to

determine the source, curtail access as needed and support forensics.

(3) --- Database Security Best Practices

http://www.applicure.com/blog/database-security-best-practice

---Separate the Database and Web Servers

Keep the database server separate from the web server. When installing most web software, the database

is created for you. To make things easy, this database is created on the same server where the application

itself is being installed, the web server. Unfortunately, this makes access to the data all too easy for an

attacker to access. If they are able to crack the administrator account for the web server, the data is readily

available to them. Instead, a database should reside on a separate database server located behind a

firewall, not in the DMZ with the web server. While this makes for a more complicated setup, the security

benefits are well worth the effort.

---Encrypt Stored Files

Encrypt stored files. WhiteHat security estimates that 83 percent of all web sites are vulnerable to at least

one form of attack. The stored files of a web application often contains information about the databases

the software needs to connect to. This information, if stored in plain text like many default installations

do, provide the keys an attacker needs to access sensitive data.

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 12

---Encrypt Your Backups Too

Encrypt back-up files. Not all data theft happens as a result of an outside attack. Sometimes, it’s the

people we trust most that are the attackers.

---Use a WAF

Employ web application firewalls (WAF). The misconception here might be that protecting the web

server has nothing to do with the database. Nothing could be further from the truth. In addition to

protecting a site against cross-site scripting vulnerabilities and web site vandalism, a good application

firewall can thwart SQL injection attacks as well. By preventing the injection of SQL queries by an

attacker, the firewall can help keep sensitive information stored in the database away from prying eyes.

---Keep Patches Current

Keep patches current. This is one area where administrators often come up short. Web sites that are rich

with third-party applications, widgets, components and various other plug-ins and add-ons can easily find

themselves a target to an exploit that should have been patched.

---Minimize Use of 3rd Party Apps

Keep third-party applications to a minimum. We all want our web site to be filled with interactive widgets

and sidebars filled with cool content, but any app that pulls from the database is a potential threat. Many

of these applications are created by programmers who discontinue support for them. Unless they are

absolutely necessary, don’t install them.

---Don't Use a Shared Server

Avoid using a shared web server if your database holds sensitive information. While it may be easier, and

cheaper, to host your site with a hosting provider you are essentially placing the security of your

information in the hands of someone else. If you have no other choice, make sure to review their security

policies and speak with them about what their responsibilities are should your data become compromised.

---Enable Security Controls

Enable key security controls on your database. Some databases nowadays will enable security controls by

default, yet prudence dictates that company’s go through and ensure your IT/DB leads check the security

controls to see if they were enabled.

Another example of DB security best industry practices is provided for a slightly different perspective

(along with a few more in this appendix). Data breaches are exceedingly costly (notification costs, fines,

etc) and very damaging to organizations (reputations, loss of business, etc). Thus this view of “Beating

the Breach: 10 Best Practices for Database Security and Compliance” is very germane as well.

https://datasafestorage.wordpress.com/2011/11/15/beating-the-breach-10-best-practices-for-database-

security-and-compliance/

In today’s interconnected world, the boundaries of our business infrastructure are constantly being

extended by the emergence of cloud, mobility, big data and more. To be useful, a company’s data must be

continuously connected to its customers, partners and employees. That exposes sensitive data to more

automated and targeted attacks than ever before. We’re now seeing numerous attacks that easily bypass

traditional perimeter defenses by exploiting Web application vulnerabilities such as SQL injection, or by

spear phishing key employees and then using stolen credentials to compromise back-end databases.

Despite more attention being paid to secure coding practices, SQL injection continues to be the #1 high-

volume signature and a favorite attack vector amongst malicious groups (see details later in this appendix

for methods to minimize this vector). Lowering compliance costs by streamlining processes is also an

important driver for implementing database security technologies. Many organizations are now looking to

replace their manual, siloed compliance processes with a single unified set of centralized, standardized

and automated controls for all key applications, database platforms and compliance mandates.

Based on engagements with Global 1000 organizations, the following best practices have emerged for

strengthening database security and compliance in enterprise environments:

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 13

---Discover: Data can’t be secured if you don’t know it exists in the first place. Discover all locations of

sensitive data including rogue databases and legacy applications. Don’t forget about non-regulated data

and corporate intellectual property (IP) such as strategic plans, product designs and proprietary

algorithms. Execute automated discovery scans on a regular basis because sensitive data locations are

constantly changing.

---Assess vulnerabilities: Once found, data classification must be applied to target levels of data

encryption and access controls for the types of data. Regularly assess database configurations to ensure

they don’t have security holes or missing patches. Use standard checklists such as the CIS Database

Server Benchmarks (very detailed, direct tasks to verify, highly recommended) and the DISA Security

Technical Implementation Guides (STIGs)(also a very detailed guide, yet more T&E related vs

‘checklist’). Don’t forget to check OS-level parameters such as file privileges for database configuration

files and database configuration options such as roles and permissions, or how many failed logins result in

a locked account (these types of database-specific checks are typically not performed by network

vulnerability assessment scanners).

---Harden the database: The result of a vulnerability assessment is often a set of specific configuration

recommendations to take as next steps. Remove all database functions and options that you don’t use.

---Audit configuration changes: Once the hardened configuration is established, continually track it to

ensure the “gold” configuration hasn’t changed. Use change auditing tools that compare configuration

snapshots and immediately alert whenever a change is made that affects your security posture.

---Deploy Database Activity Monitoring (DAM) and Database Auditing: Continuous, real-time

monitoring is crucial for rapidly detecting suspicious or unauthorized activity – such as a customer

service rep downloading hundreds of customer records in a single day. Monitoring privileged users —

such as DBAs, developer and outsourced personnel — is also a requirement for most compliance

regulations, as well as for detecting intrusions from outside attackers, since cyber attacks frequently result

in the attacker gaining control of privileged accounts. DAM is also essential for finding “behavioral

vulnerabilities” such as users sharing privileged credentials. Database auditing allows organizations to

generate a secure, non-repudiable audit trail for all critical database activities — such as creation of new

accounts and viewing or changing sensitive data — and it’s also important for forensic investigations.

---Authenticate, control access and manage entitlements: Controlling access to sensitive data on a “least

privilege” basis is essential to ensuring full accountability. You should also periodically review

entitlement reports as part of a formal audit process.

---Monitor the application layer: Well-designed DAM solutions associate specific database transactions

performed by the application with specific end-user IDs, in order to deterministically identify individuals

violating corporate policies. In addition, combining database auditing information with OS and network

logs via a security information and event management (SIEM) system to see everything that a user has

done can also provide critical information for forensic investigations.

---Encrypt: Encryption renders sensitive data unreadable, so an attacker can’t gain unauthorized access to

data from outside the database. File-level encryption at the OS layer, combined with granular real-time

monitoring and access control at the database layer, is typically accepted as a practical alternative to

column-level encryption and a compensating control for Requirement 3.3 of PCI-DSS.

---Mask test data: Masking is a key database security technology that de-identifies live production data,

replacing it with realistic but fictional data that can then be used for testing, training and development

purposes, because it is contextually appropriate to the production data it has replaced.

---Automate and standardize compliance processes: Most compliance regulations require implementation

of data security measures to reduce risks to a reasonable and appropriate level. Achieving compliance is

not only important because no one likes to fail an audit, but it also provides third-party validation that

your organization has implemented the proper controls to ensure the confidentiality, integrity and

availability of your data. Automating and standardizing compliance processes is essential for reducing

compliance costs, minimizing last-minute audit fire drills and easily addressing ever-changing

regulations.

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 14

(4) - Mandatory Restricted Systems Security Standards for highly sensitive data

--- General

Database servers should have as little accessibility and visibility to the Internet as possible. When, for

example, an Internet-accessible web server is used as a front end for a database application, the database

should not be on the Web server host itself. In addition, the database host or network firewall should deny

all traffic except for specific, static IP addresses and ports of application and interface servers

Database server and application server host register in the “Tenable” vulnerability scanning system and

be subject to routine security scans

Back-up files should be encrypted where possible (especially when transporting off-site). If the database

is encrypted, the back-ups will usually be encrypted also. If not, consider using back-up tools that will

encrypt data and utilize practical key management solutions

Application interfaces should include banners in accord with MISP policies discussing user

responsibilities regarding confidentiality and privacy of restricted data.

---Access Control

Consider using automated tools, group privileges and policies should be used to enforce common sense

security precautions, such as disabling null user session access and renaming built-in administrator

accounts

Avoid hard coding passwords into connection strings in database applications

Consider removing the local administrative groups from the database roles and replacing it with a custom

local group with only true database administrators. This may not prevent local administrators from

granting themselves any access they wish, but at least these actions would be auditable

---Encryption

Database files with restricted information stored on mobile devices (e.g. laptops, back-up tapes) or at risk

workstations (e.g. in public areas) must be secured through encryption and strong passwords -- or

equivalent authentication

Protect credentials (and similarly highly sensitive restricted information) through encryption. Consider

using SSL certificates

When transmitting data or replicating databases across an un-trusted network, encrypt data (e.g. SSL,

point-to-point VPN tunnels)

---Monitoring

Document a host and application audit plan that should include new threats, vulnerabilities, and object

access failure statistics (e.g. MOM, Tripwire)

Regularly audit user group or role access

Regularly audit the execute permissions on stored procedures. User logins rarely need execute

permission. When in doubt, grant permission only to the administrator roles

(5) - Key Oracle DB security items to manage (and from which a list of CIs is distilled and documented in

this section, all of which is must be agreed to by both IT/OPS & SEC):

---INSTALL ONLY WHAT IS REQUIRED

The Oracle Database software installation has two modes - typical and custom. For production systems,

the custom installation mode can be used to install the minimum set of features and options required. For

production environments, Oracle recommends you do not install the sample schemas.

---LOCK AND EXPIRE DEFAULT USER ACCOUNTS

The Oracle database installs with a number of default (preset) user accounts. Each account has a default

(preset) database password. After successful installation of the database the database configuration

assistant (DBCA) automatically locks and expires most default database user accounts. In addition, the

password for accounts such as SYSTEM are changed to the value specified during database installation.

---CHANGING DEFAULT USER PASSWORDS

Choosing secure passwords and implementing good password policies are by far the most important

defense for protecting against password based security threats.

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 15

---CHANGE PASSWORDS FOR ADMINISTRATIVE ACCOUNTS

While you can use the same password for administrative accounts such as SYSTEM, SYSMAN and

DBSNMP, Oracle recommends using different passwords for each.

---CHANGE DEFAULT PASSWORDS FOR ALL USERS

All accounts are installed with a default password that is the same as the user account. If any of these

accounts is unlocked, assign a new stronger password. Starting with 11g security administrators can

easily check for default passwords by using the new database view DBA_USERS_WITH_DEF_PWD.

---ENFORCE PASSWORD MANAGEMENT

Enforce failed login, password expiration, password complexity and reuse policies using Oracle profiles

and follow best practices. Oracle 11g and up provides an optional installation choice that will pre-

configure a default profile to enforce password expiration and reuse. Oracle recommends that basic

password management rules be applied to all user passwords and that all users be required to change their

passwords periodically.

---SECURE BATCH JOBS

The Secure External Password Store feature introduced with 10gr2 is designed to help secure batch jobs

that authenticate to the database using username / password credentials. It is very important that the

permissions on the Oracle “Wallet” containing the username and password be set accordingly as anyone

with access to the Wallet could use it to authenticate to the database.

---MANAGE ACCESS TO SYSDBA AND SYSOPER ROLES

Special attention should be given to managing access to the SYSDBA and

SYSOPER roles. Oracle recommends customers refrain from connecting with the SYSDBA role except

when absolutely required such as called for by an existing Oracle feature or patching. Oracle will be

eliminating all dependencies on direct connections using SYSDBA. Organizations should create separate

administrative accounts.

---ENABLE ORACLE DATA DICTIONARY PROTECTION

Oracle recommends that customers implement data dictionary protection to prevent users who have the

"ANY" system privileges from using such privileges to modify or harm the Oracle data dictionary. To

enable data dictionary protection, set the O7_DICTIONARY_ACCESSIBILITY parameter to FALSE.

---FOLLOW THE PRINCIPLE OF LEAST PRIVILEGE

Oracle recommends you avoid granting powerful privileges to new database users, even privileged users.

The Oracle DBA role should be granted with caution and only to those privileged user who need full

DBA privileges. Special attention should be given when assigning privileges to application schemas.

Access to the SYSDBA role should be granted with extreme care and only to those who are in the most

trusted position. Auditing should be used to monitor all activities of users connecting with the SYSDBA

role or other administrative roles such as the DBA role, CREATE ANY TABLE privilege and so forth.

For optimal auditing performance set your audit destination to point to the operating system.

---PUBLIC PRIVILEGES

The topic of PUBLIC privileges is part of Oracle's overall secure-by-default initiative that started with

Oracle Database 9i. New in the Oracle Database 11g release are granular authorizations for numerous

PL/SQL network utility packages granted to PUBLIC. Depending on the application model, it may be

possible to remove grants from the PUBLIC user group by first making grants directly to the application

schema or end user (depending on the application model) and then revoking the privilege from the

PUBLIC user group.

---RESTRICT PERMISSIONS ON RUN-TIME FACILITIES

When granting permissions on run-time facilities such as the Oracle Java Virtual Machine (OJVM), grant

permissions to the explicit or actual document root file path.

--- AUTHENTICATE CLIENTS

Oracle recommends verifying that the database initialization parameter REMOTE_OS_AUTHENT is set

to FALSE. Setting the value to FALSE creates a more secure configuration by enforcing server-based

authentication of clients connecting to an Oracle database.

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 16

---RESTRICT OPERATING SYSTEM ACCESS

Limit the number of users with operating system access on the Oracle Database host. Oracle recommends

restricting the ability to modify the default file and directory permissions for the Oracle Database home

(installation) directory or its contents. Restrict usage of symbolic links on the operating system. When

providing a path or file to the Oracle database, neither the file nor any part of the path should be

modifiable by an un-trusted user.

---SECURE THE ORACLE LISTENER

The Oracle Listener should be properly configured for optimal security. Oracle Database 10g Release 1

and higher uses local OS authentication as the default authentication mode. This mode requires the Oracle

Net administrator to be a member of the local DBA group. Setting a password for the TNS listener in

Oracle Database 10g Release 1 and higher simplifies local administration. When the

ADMIN_RESTRICTIONS_LISTENER is set to ON (Default) runtime changes to the listener parameters

is disabled. You should also consider using a firewall.

---SECURE EXTERNAL PROCEDURES

The default configuration for external procedures no longer requires a network listener to work with

Oracle Database and EXTPROC agent. The EXTPROC agent is spawned directly by Oracle Database and

eliminates the risks that extproc might be spawned by Oracle Listener, unexpectedly.

---CHECKING NETWORK IP ADDRESSES

Use the Oracle Net valid note checking security feature to allow or deny access to Oracle server processes

from network clients with specified IP address.

---HARDEN THE OPERATING SYSTEM

Both UNIX and Windows platforms provide a variety of operating system services, most of which are not

necessary for most deployments. Such services include FTP, TFTP, TELNET and so forth. Be sure to

close both the UDP and TCP ports for each service that is being disabled. Disabling one type of port and

not the other does not make the operating system more secure.

--- ENCRYPT NETWORK TRAFFIC

Encrypt network traffic between clients, databases and application servers. Oracle supports both SSL

using X.509v3 certificates as well as native network encryption without certificates.

---APPLY ALL SECURITY PATCHES

Always apply relevant security patches for both the operating system and Oracle – Use an ITAM / CMDB

process to track and manage patches. Periodically check the Oracle Technology Network (OTN) security

site for details on security alerts released by Oracle. Also check Oracle Worldwide Supports services site,

Metalink.

(6) - Another reference set of Best Practices for Database Security

http://docs.media.bitpipe.com/io_10x/io_103497/item_511521/McAfee_sSecurity_IO%23103497_E-

Guide_101012.pdf

Regarding the host operating system on the server that supports the database, the following best practices

should be in place:

1. System administrators and other relevant IT personnel should have adequate knowledge, technical

skill-sets and an understanding of all critical operating system security requirements.

2. Industry-leading configuration standards and supporting internal documentation should be utilized

when deploying operating systems into the managed services environment.

3. Only necessary and secure services, protocols, daemons and other essential functions should be enabled

on the operating systems.

4. All unnecessary functionality and all insecure services and protocols should be effectively disabled on

the operating systems.

5. Root accounts should be appropriately secured with the selection of a unique password that is changed

on a regular basis.

6. Root accounts should be restricted to the fewest number of personnel necessary.

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 17

7. Syslog should be configured for sending and copying syslog data to a central syslog server, for which

log information is reviewed.

8. The principle of "least privilege," which states users are only given privileges that are required to

efficiently and properly perform their job function, should be in place regarding operating system access

rights.

9. All relevant and critical security patches should be applied to operating systems as warranted.

For the actual database itself, the following Database Monitoring Best Practices: Using DAM Tools are

recommended:

1. A list of authorized users who have access to databases within the managed application services

environment should be maintained and kept current by appropriate personnel.

2. System administrators and other relevant IT personnel should have adequate knowledge, technical

skill-sets and an understanding of all critical database security requirements.

3. Industry-leading configuration standards and supporting internal documentation should be utilized

when deploying databases into the managed services environment.

4. Default user accounts that are not necessary for database functionality should be locked and expired.

5. For all user default accounts that remain in use, passwords should have been effectively changed to

invoke strong password measures.

6. Administrative accounts within the databases should have different passwords assigned to them, with

no shared or group passwords being used for these accounts.

7. Measures should be in place for protecting the data dictionary and the supporting metadata that

describes all objects in the database.

8. For any host-based authentication measures in place for accessing the database, appropriate procedures

should be in place for ensuring the overall security of this type of access.

9. Database monitoring should be in place consisting of tools that alert appropriate personnel as needed.

10. All relevant and critical security patches should be applied to the databases as warranted.

(7) - Top 6 things every database security solution should include

http://www.hexatier.com/top-6-things-every-database-security-solution-should-include/

---Compliance: Monitoring and Auditing

Let’s be honest about compliance. Compliance is important, and many of the compliance regulations

relate to real problems that every enterprise needs to give attention. Compliance is a part of IT security,

but much of the regulation on database security focuses on monitoring rather than real-time prevention.

It’s essential to have, though it is not enough.

Database Activity Monitoring (DAM) is one of the major elements of compliance. DAM identifies every

activity on the database, creating alerts and reports about the activity.

The purpose of compliance, for your organization, is to comply with the standards bodies relevant for

you, whether that’s PCI-DSS, SOX, HIPAA, or any international compliance standard.

Using DAM, you can identify exactly which individuals and entities are accessing the database, and for

what purposes. To comply with most standards bodies, you need to have full accounting of who did what

when.

All database protection solutions will include tools for detecting and alerting of any database activities

that deviate from standard policy, or are suspicious. You should set up alerts of all suspicious behavior so

that you can handle issues in real-time, even if they are blocked by a database firewall.

Monitoring also includes what people didn’t do: for example if administrators fail to change their

password regularly, or if there are individuals who have database privileges but never log in. The

information of lack of activity can also be essential, allowing you to revoke unused privileges that could

be exploited.

---Access Control: Separation of Duties

Access control, or separation of duties, fundamentally protects from insider attacks. Insider attacks may

be intentional, but just as frequently, insider attacks may be a result of theft of credentials.

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 18

Separation of duties allows you to assign privileges to the administrators and user of the database

according to their needs. So, for example, someone who is in charge of backup and storage of the

database may never need to see the actual contents of the database. Someone who is performing testing

may need access to the database, but may not need to see actual data. Using separation of duties allows

you to define each of these roles and limit use to the minimum needed for each user or type of user.

In other words, separation of duties is about controlling user behavior and managing individual entities.

By allowing each user to perform only the activities under their jurisdiction, separation of duties protects

the database from both intentional and inadvertent breaches.

All databases include powerful tools for implementing separation of duties, with a large range of access

controls and privileges. In addition to the built-in tools, database firewalls can automatically detect what

users are on the system, and allow you a higher level of control of privileges on a table or even column

basis.

--- Query (SQLi) protection

The primary way to access a database is through SQL commands. Therefore, the most important

protection on a database is SQL injection (SQLi) attack protection. Database protection includes a

firewall that has a good set of built-in SQLi white list and black list definitions as well as overflow

protection and the ability to customize your own policies. Most database firewalls have monitoring

capabilities that can learn your organization’s behavior for your organization, so that the baseline gets

better over time at recognizing legitimate and illegitimate use of your database.

Some companies refer to something called “Vulnerability Patching”. Typicaly, SQLi protection and data

masking are what they offer. If your database is set up so as to be inaccessible, any vulnerabilities that are

not patched will be difficult to exploit. You still need to update your software regularly, but this layer of

protection can avoid many nasty potential breaches.

--- Data Masking

Databases often contain information that should not be viewed by the administrators, although they need

to use the data in some way. While the admins need access to the entire database, they should not actually

be allowed to view data such as customer names, financial data, etc. Data masking garbles the data so that

when it is extracted from the database, the format is preserved, but the data is unreadable.

Data masking can be taken one step further for development and testing purposes. Developers and testers

need access to the database in order to create new functionality and upgrade existing functionality. To

perform development tasks, it’s essential for developers to have database access, however they are not

allowed to see actual data. Using dynamic masking, database developers can work on the data and view

the format of data without seeing the actual information. Using static data masking, an entire duplicate

database is created and all data is masked to block developers and testers from seeing the actual account

data.

---Encryption

Database encryption is an essential part of protecting your database, and there are different levels of

encryption. First of all, the entire database can be encrypted using encryption tools. This means that even

if someone had access to the physical database, or was able to tap in some other way, the data would not

be readable. It is necessary to have encryption keys when accessing the database.

The second level of data encryption is really only relevant outside the database. Every piece of data that

leaves the database in any format should be protected from malicious access. Typically, this level of

encryption is handled on the transport level by encrypting the channel. It’s important to make sure that

your data is properly encrypted wherever it travels outside of the database

(8) – Basic DB security - step by step

http://searchsecurity.techtarget.com/magazineContent/Basic-Database-Security-Step-by-Step

This is a “quick” checklist to cover database configuration, data safeguards, account provisioning,

OS/database interaction and considerations for front-end applications that use the database. Without these

foundational sanity checks in place, many elaborate database security measures are a waste of time.

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 19

These are the rudimentary security measures that you must take to protect the database from common

threats. While they may take time to investigate and effort to perform, they are easy and effective!

A---ACCESS CONTROLS AND AUTHORIZATION STEPS You may be tempted to skip ahead because you think you already have access controls in place, and then

promptly fail a security review. Just because you have an access control system does not mean your

system is secure. Database authentication and domain authentication are different, and great care must be

taken so these two systems coordinate access and don't allow users to bypass database authorization

entirely.

This is your first line of defense for database and data security, and it warrants close inspection to ensure

proper configuration of accounts, as well as proper deployment of the two systems. Keep in mind that the

longer a database has been in operation, the more access rights drifts away from a secure baseline.

Change default user passwords immediately upon installing the database. Periodically verify they

have not reverted because of a reinstall or account reset.

Lock user accounts not in use. If you are certain they will never be used, remove them. This is

especially important with canned database testing, tutorials or demonstration users. These known

accounts are packaged with the database, and are exploitable to gain access to data and database

functions.

Enforce stronger passwords. If you are using domain-level access to control database

authorization, then you can set policies for stronger passwords. Our recommendation is you rotate

passwords, and move away from static passwords.

Remove public accounts, as well as public access from all accounts. There is no use case where

you want the general public to have access to your database.

Choose domain authentication or database authentication for your database users, and stick with

it. Do not mingle the two. Confusion of responsibility will create security gaps.

Examine roles and groups closely. List out user permissions, roles and group participation, and

review it to make sure users have just enough authorization to do their job. Unfortunately,

depending upon the number of users in your database, this can be time consuming. Even when

automation tools collect permissions assigned to each user account, manual review of settings is

still required to detect problems. The bad news is this is not fun, and for large databases, you

should plan on spending a day to get the permissions mapping right. The good news is once it is

set, it is much easier to detect unwanted changes and stop escalated privileges.

Protect administrative functions from users. Database vendors list functions, roles, stored

procedures and utilities dedicated for administration. Do not delegate these functions to users.

Divide database admin duties. For companies with more than one database administrator, divide

administrative tasks between different admins, operating under different administrator accounts.

The relational database platforms provide advanced access control provisions to accomplish this,

allowing both for separation of duties, as well as locking down the master DBA account.

B---ASSESS DATABASE CONFIGURATION This is very important for determining security and operational integrity.

Find out how your databases are configured, either through database queries and analysis of

configuration files, or via a freely available assessment tools. All database vendors recommend

configuration and security settings, and it does not take very long to compare your configuration

to the standard.

Remove modules and services you don't need. Not using replication, for example? Then remove

those packages. These services may or may not be secure, but their absence assures you are not

leaving an open door for hackers.

Document approved configuration baseline for databases. This should be used for reference by

all administrators, as well as a guideline to detect misconfigured systems.

Use scanning tools to discover the databases you have, and be consistent when applying

configuration settings.

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 20

C---ASSESS DATABASE/PLATFORM INTERACTION All databases provide means to directly call operating system commands for administrative tasks. These

functions are comprised of OS and database code, running under administrative permissions, and offering

a bidirectional portal to the database. These recommendations are meant to close security holes along this

boundary.

Disable extended or external stored procedures.

Ensure the database owner account on local platform, under which the database is installed, is

not assigned domain administrator functions.

Make sure domain administrators are not database administrators.

Tie import/export utilities, startup scripts, registry entries or properties files to the local database

owner credentials.

D---SECURE COMMUNICATIONS You want to make sure that communications to the database are kept private.

Encrypt sessions between applications and the database, especially Web application connections.

Reset database port numbers to non-default value. For example, moving Oracle's default port of

1521 to a random value defeats automated attacks, and makes it harder for an attacker to probe

for information.

Block ad-hoc connections. Ad-hoc connections from undesired locations, time of day or through

unapproved applications can be detected and rejected by simple login triggers, database firewalls

and some access control systems.

E---PATCH THE DATABASE Your goal is to leverage the security knowledge and expertise of the database vendor, allowing them to

find and address security issues. This requires certifying and installing patches on a regular basis.

Create an environment and process to perform a sanity functions check on database patches prior

to production deployment.

Don't allow patch downloads by individual DBAs; Rather have centralized, approved and

verified copies available.

Synch internal patch cycles with vendor patch releases.

Reconfigure in the cases where patch or alteration of functions is unacceptable. If you employ

database/Web application firewalls, determine if you can block the threat until a suitable patch is

available.

F---APPLICATION USAGE OF THE DATABASE Enterprise and Web applications leverage more than basic data storage, using service accounts that are

provisioned with a broad range of capabilities.

Segment the authorization between common users and application administration accounts.

Restrict connection pooling where a single database account is leveraged by all database users. If

possible, divide the application processing into different groupings, and perform these operations

under different database user accounts. In addition, access permissions can be minimized in

accordance with the role as it provides segregation of duties and makes log file analysis easier.

Modify the application-to-database connection to allow for database queries to be associated with

an end user. This makes audit analysis and policy enforcement easier.

G---MEDIA PROTECTION Protecting backup media is not optional because lost media is the leading cause of data breaches. There

are several methods available that do not require alteration of processes or applications, including

database transparent encryption, which requires no changes to application code and is often available free

from the database vendor.

H---LOG AND EVENT REVIEW

Use logging if you can.

Create a log retention policy, determine what events you don't need and filter them out.

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 21

Review logs periodically, focusing on failures of system functions and logins that indicate system

probing.

Review log settings periodically.

I---EMBRACE INSECURITY No matter what you do, you will never be 100 percent secure. Take this into account, and plan your

response to security events.

Inventory your databases.

Discover and catalog your sensitive data.

Have a plan on what to do if data is lost or stolen.

Have a disaster recovery plan.

Create a cooperative culture, get to know the applications developers and administrators, and

make sure they understand that everyone needs to work together. If you have a compliance group,

get to know them, and ask for their advice and opinions.

J---COMPLIANCE FORCES ENCRYPTION, AUDITING If you have valuable data, odds are you have an industry or governmental obligation to perform the

following recommendations. They are good security practices for everyone, but as it costs additional time

and money to implement, they were largely ignored prior to regulatory pressure. The two most commonly

prescribed regulatory requirements are auditing and encryption. These functions can be accomplished

with the tools provided by the database vendor, but given the difficulty of implementation, deployment

and management of these systems, you will be purchasing additional tools and platforms to alleviate day-

to-day management and performance issues.

Auditing. Database auditing is used to capture a record of database transactions, which is then used to

detect suspect activity and perform forensic audits. All of the relational database platforms have auditing

features that capture transactions on the data and administrative operations against the database system.

Depending upon the vendor and how the feature is deployed, you can gather detailed transactional

information, filter unwanted transactions to capture a succinct view of database activity, and do so with

only modest performance impact.

Using the standard software provided by database vendors will be ample to collect needed data, but you

will need to develop a review process and reports to demonstrate compliance. Database auditing

monitoring and log management tools are also available to automate these efforts. While the latter

requires additional investment, these tools provide better performance, are easier to use, and have prebuilt

policies and reports specifically designed for regulations.

Encryption. There are many forms of database encryption available, but they typically break into two

families: transparent encryption that covers the entire database and requires no modifications to business

processes, and user encryption applied only to select objects within the database that requires alteration of

the application code. Transparent encryption is really designed to protect data on media, such as disk

drives and backup tapes, from being accessed outside of the database. User encryption can be used for

both media protection and protecting data from misuse.

When we discuss encryption to meet regulatory mandates, transparent encryption options are not suitable

measures to meet requirements such as the Payment Card Industry Data Security Standard (PCI DSS), but

they do satisfy most state data breach notification law requirements. As the cost and complexity is

radically different between these two options, you will need to discuss which is appropriate to satisfy your

auditors before deciding upon a course of action. Make sure you are addressing the right threat before

deciding how you are going to implement database encryption. You can begin any of these actions now,

and they are proven effective at preventing the most common database attacks. Better still, the basic steps

are free, and with a little of your time and energy, they can be completed without having to purchase

specialized products or services. You can buy aftermarket products to perform these tasks, and they will

do the job better, faster and with less effort on your part.

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 22

(9) – Suggested / proposed SANS / DB encryption methods

These methods are explained in great detail, with rationale, in Security’s “Enterprise Encryption

Strategy.” A high level overview is provided at the end of this appendix.

(9) SQL injection special case of high DB risks.

Again, several good sources are available to develop a process / checklist to minimize the likelihood of a

SQL injection attack. The KEY entrance vector is poor software development practices, lack of

embedding security into the SDLC. SQL injection is a code injection technique, used to attack data-

driven applications, in which malicious SQL statements are inserted into an entry field for execution (e.g.

to dump the database contents to the attacker). SQL injection must exploit a security vulnerability in an

application's software, for example, when user input is either incorrectly filtered for string literal escape

characters embedded in SQL statements or user input is not strongly typed and unexpectedly executed.

SQL injection is mostly known as an attack vector for websites but can be used to attack any type of SQL

database. SQL injection attacks allow attackers to spoof identity, tamper with existing data, cause

repudiation issues such as voiding transactions or changing balances, allow the complete disclosure of all

data on the system, destroy the data or make it otherwise unavailable, and become administrators!

--- These are ten overall ways to help prevent or mitigate SQL injection attacks:

1. Trust no-one: Assume all user-submitted data is evil and validate and sanitize everything.

2. Don't use dynamic SQL when it can be avoided: used prepared statements, parameterized queries or

stored procedures instead whenever possible.

3. Update and patch: vulnerabilities in applications and databases that hackers can exploit using SQL

injection are regularly discovered, so it's vital to apply patches and updates as soon as practical.

4. Firewall: Consider a web application firewall (WAF) – either software or appliance based – to help

filter out malicious data. Good ones will have a comprehensive set of default rules, and make it easy to

add new ones whenever necessary. A WAF can be particularly useful to provide some security protection

against a particular new vulnerability before a patch is available.

5. Reduce your attack surface: Get rid of any database functionality that you don't need to prevent a

hacker taking advantage of it. For example, the xp_cmdshell extended stored procedure in MS SQL

spawns a Windows command shell and passes in a string for execution, which could be very useful

indeed for a hacker. The Windows process spawned by xp_cmdshell has the same security privileges as

the SQL Server service account.

6. Use appropriate privileges: don't connect to your database using an account with admin-level privileges

unless there is some compelling reason to do so. Using a limited access account is far safer, and can limit

what a hacker is able to do.

7. Keep your secrets secret: Assume that your application is not secure and act accordingly by encrypting

or hashing passwords and other confidential data including connection strings.

8. Don't divulge more information than you need to: hackers can learn a great deal about database

architecture from error messages, so ensure that they display minimal information. Use the "RemoteOnly"

customErrors mode (or equivalent) to display verbose error messages on the local machine while ensuring

that an external hacker gets nothing more than the fact that his actions resulted in an unhandled error.

9. Don't forget the basics: Change the passwords of application accounts into the database regularly. This

is common sense, but in practice these passwords often stay unchanged for months or even years.

10. Buy better software: Make code writers responsible for checking the code and for fixing security

flaws in custom applications before the software is delivered. SANS suggests you incorporate terms from

this sample contract into your agreement with any software vendor.

http://www.enterprisenetworkingplanet.com/netsecur/article.php/3866756/10-Ways-to-Prevent-or-

Mitigate-SQL-Injection-Attacks.htm

http://www.veracode.com/security/sql-injection

https://docs.oracle.com/cd/E58500_01/pt854pbh1/eng/pt/tpcd/task_PreventingSQLInjection-

0749b7.html#topofpage

To collaborate on the this DB MSB contact Mike.Davis.SD@gmail.com 23

(10) - Data at rest encryption

Critical data sitting on company storage should be encrypted using symmetrical encryption methods (i.e.,

AES-256), in which the key used is protected using Asymmetric algorithms (i.e., RSA 2048) leveraging an

HSM (ie Thales). An organizational encryption policy is required before implementing any data security

strategy. Failure to be thorough in an end-to-end encryption strategy will present significant risk to the data in

several ways. Several data-at-rest methods are discussed below.

Common Internet File System (CIFS) (flat file)

One can leverage Microsoft’s EFS to protect the data against forced theft (someone steals the server or disk)

and to protect it against someone directly accessing it (build a new server and attach it to the SKU). However,

this doesn’t protect the data from someone with valid access. This may seem confusing but it really means that

if someone manages to steal the credentials of a valid user then that attacker would be able to simply copy the

data off and circumvent the protections provided by EFS. Also consider self-encrypting drives and/or HDD

controller encryption for new installations and technology refresh periods.

To mitigate the credentials issue we will evaluate certain rights management checks or computer posture

validation as a secondary gatekeeper to prevent unauthorized persons access, even though they may have valid

credentials, from stealing our data. If the server is stolen, the data cannot be recovered because the key is not

stored on the server but rather the HSM. If the HSM is stolen along with the server then we can employ

“quorum” methods that prevent it from being brought back online outside our environment (several people

have to be involved to bring an HSM online after a reboot).

Database (SQL) Like CIFS, SQL does support encryption using vendor specific technologies but in order to get the most out of

SQL encryption, some customization should be performed. This may sound like a contradiction to the flat-file

encryption concept but it does have merit. Combining DRM with database security can be difficult to

implement so we need another solution to prevent the “stolen credentials” issue. We’ll assess the methods

database servers generally employ to encrypt data. Gartner suggest folks consider third-party encryption

solutions to enable centralized management of multiple vender RDBMSs as well as support cloud encryption

gateways.

Whole DB encryption – This method encrypts the entire database including all tables, views, stored procedures,

triggers and indices. This is the method of choice for most developers because it’s very easy to implement and

doesn’t require any changes to their programming techniques. However, what they usually fail to realize is that

whole DB encryption is really only good for protecting the data when someone steals the entire server. It is

less effective against someone with valid credentials including DBAs which you many not want accessing

your sensitive data.

Column level encryption – Column level encryption encrypts data one column at a time and doesn’t require

that all of the data be encrypted. Unlike whole DB, column can protect the data against the DBA. Column level

also provides more flexibility in that different columns can be protected with different keys. This flexibility,

however, comes with some tradeoffs. 1) Applications should be coded to support column encryption;

specifically to determine who can access the data and when. 2) Searching performance can be significantly be

reduced. 3) You cannot protect the intellectual property of the DB such as the design, queries, and views.

Cell level encryption – Encryption at this level is performed solely by the application. This encryption has the

most flexibility because the application determines all aspect of encryption including key management. The

tradeoffs for this, however, are pretty severe. Applications must be custom written to support cell level

encryption and SQL features such as Indexes and stored procedures are nearly impossible to use. In our design,

we will use implementations of all three with a little heavier focus on cell level encryption. Even though they

all have some very appealing features, only cell level offers flexibility with key management. As a caveat to

this approach, we will test SQL 2014 which allows use of certificates which are likely protectable with an

HSM.