Post on 26-Jun-2018
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.