1. Database Security and Data Governance
Best Practices for
Database Security and Data Governance
Nir Carmel
Product Manager

2. Protecting your physical assets

3. Protecting your assets - safe

4. Protecting your assets – vault

5. Protecting your assets – procedures & monitoring

6. Protecting your assets – audit & assurance
regulation

7. Protecting your digital assets
Digital assets aren't any different than physical assets
If I entrust my jewelry to a repair store and it gets stolen, they're liable for the loss.
Identity theft is as painful as any other theft of a physical assets
Most of our assets are digital
Digital assets are much harder to protect
Accessibility
Transferability
Flexibility (prone to changes)
Technical Knowledge
Complexity & backdoors
Internal threats
Separation of duties
Higher Risks
Theft volumes
Theft periods (continuity)
Potential threats

8. Top Regulations Impacting DB Security
Audit Requirements
CobiT (SOX)
PCI DSS
HIPAA
CMS ARS
GLBA
ISO 17799
(Basel II)
NERC
NIST
(FISMA)
1. Access to Sensitive Data
(Successful/Failed SELECTs) 
2. Schema Changes (DDL) (Create/Drop/Alter Tables, etc.)
3. Data Changes (DML)
(Insert, Update, Delete)
4. Security Exceptions
(Failed logins, SQL errors, etc.)
5. Accounts, Roles & Permissions (DCL)
(GRANT, REVOKE)
1. DDL = Data Definition Language
AKA “schema changes”
Manipulates database structure
CREATE, DROP, ALTER objects such as TABLES
2. DML = Data Manipulation Language
Manipulates & retrieves data
INSERT, UPDATE, DELETE and SELECT
3. DCL = Data Control Language
Controls access
GRANT & REVOKE
CONNECT to the database or schema.
SELECT, INSERT, UPDATE, DELETE records.
USAGE -- use a database object such as a schema or a function
DDL = Data Definition Language (aka schema changes)
DML = Data Manipulation Language (data value changes)
DCL = Data Control Language

9. STIG

10. STIG Database Security Technical Implementation Guide (Database STIG)
Developed by the Defense Information Systems Agency (DISA) for the Department of Defense (DOD)
Published to the public domain
Considered the best practice/blueprint to achieve a secure database environment
Includes directives for all DBMS and specific guidelines for Oracle, SQL Server and DB2
Provides a clear distinction between responsibilities of the
Database Administrator (DBA)
System Administrator (SA)
Information Assurance Officer (IAO)

11. STIG Document Overview
Integrity
Software
Development & Production
Data Integrity
Ad Hoc Queries
Discretionary Access Control
Database Accounts Control
Authentication
Database Authorization (Roles, Grants)
Protecting Sensitive Data, Stored Application, Database F iles
Network Access
Database Identification Parameters
Remote Connections
Database Replications & Database Links
Operating System
Database Files Access
Local Database Accounts
Database Administration Accounts
Database OS Groups
Appendices
Database specific scenarios & scripts (Oracle, MSS, DB2 )

12. STIG Generic Requirements - Integrity
Version verification, support for the version, patches etc.
The IAO will ensure that unsupported DBMS software is removed or upgraded prior to a vendor dropping support.
The IAO will ensure that the site has a formal migration plan for removing or upgrading DBMS systems prior to the date the vendor drops security patch support.
The IAO will ensure that the DBMS version has all patches applied.
Weekly (or more frequent) monitoring of the objects code to ensure that they have not been modified; baselines must be generated. This also includes functions and procedures
The IAO will ensure that DBMS software is monitored on a regular basis no less frequently than weekly to detect unauthorized modifications.
The DBA will provide to the SA and IAO a list of database software directories to be included in software backup, baselining, and monitoring.
The IAO will ensure that configuration management policies and procedures are implemented for database software modifications.
Third party software, Install dir
The SA will make sure that third party software should not be installed on the same directory structure as the database directory structure.
DDL Commands
The IAO will ensure that database applications do not use DDL statements.

13. STIG Generic Requirements (cont)
Unused Components
The IAO will ensure that all unused binaries, database accounts, database objects, etc. will be removed
Software development limitations
The DBA will ensure that software development on a production system is separated through the use of separate and uniquely identified data and application file storage partitions and processes/services.
The IAO will ensure that software configuration management policies are implemented and strictly enforced to ensure untested software is not inadvertently loaded to production systems.
The DBA will ensure that no database links are defined between production and development databases.
The DBA will ensure that development applications do not access production databases unless justified and documented with the IAO.
The DBA will ensure that development databases created from production database exports have passwords changed from their production values.
The DBA will ensure that export data from a production database used to populate a development database has all sensitive data such as payroll data or personal information, etc., removed or modified prior to import to the development database.
The IAO will review privileges granted to developers on shared production/development database systems to modify application code or application objects every three months or more frequently.
De-identification, data sanitization, data obfuscation, …
Princeton Softech (IBM)
Applimation
Datamasking.com – camouflage

14. STIG Generic Requirements (cont)
File permissions
The SA will ensure that permissions to database software comply with security evaluation specifications. If unavailable, permissions to database software will be set to comply with vendor recommended permissions.
The SA will ensure that all directories created by the installation of the DBMS are protected in accordance with security evaluation specifications if available. If unavailable, DBMS directory permissions will be set to comply with vendor recommendations.
The SA will ensure that all file permissions created by the installation of a DBMS are modified as necessary to comply with security evaluation specifications if available. If unavailable, DBMS file permissions will be set to comply with vendor recommended permissions.
The SA will ensure that permissions to change directory names, file permissions, or group information associated with the database software are restricted to SAs and DBAs.
The SA will ensure that all DBMS and third-party database application software files and directories are owned by the application software installation account and are protected from access by more than the minimal number of users required.
More…
Backups, recovery
Performance analysis

15. STIG – Discretionary Access Control
Database Account Controls
The DBA will ensure that all database actions are traceable to an individual user.
The DBA will ensure that all database accounts are granted roles containing the minimum set of privileges required for the application.
The DBA will configure all database accounts to be protected by a password, certificate, or other approved authentication method.
The DBA will ensure that use of shared database accounts are justified and documented with the IAO.
Authentication
- Encourage the use of PKI (DOD PKI, )
Password Guidelines
The DBA will assign a temporary database account password at account creation.
The DBA will ensure that database account passwords…
are stored in an encrypted format.
are hardened - minimum of eight chars, upper/lower case, digits, special char.
don’t contain personal information, dictionary words, etc.
are changed every 90 days or more frequently.
Are different from previous ones by at least 4 characters
not reused within 10 passwords and within a year.
The DBA will ensure that application database account passwords are changed at least once a year and anytime an application administrator is reassigned.
The DBA will disable all default database account immediately after installation.
The DBA will lock the database account after three failed logins
Password expiration – not for functional accoutns but need to document it
Use monitoring/alerting instead.

16. STIG – Database Accounts
Application Connection Pool Accounts
The DBA will ensure that access to a shared database N-Tier connection account is restricted by network configuration and authentication method to the connecting middle-server.
The DBA will ensure that the acceptance of risk for the limited auditing capability of the database in a shared N-Tier connection account configuration is documented and filed with the IAO.
The DBA will configure connections between the database server and connecting middle tier system in accordance with policy as listed in Section 5.2, Network Connections to the Database.
Application User Database Accounts
The DBA will ensure that privileges granted to application user database accounts are restricted to those required to perform the specific application functions assigned.
The DBA will ensure that privileges are not directly granted to database application user database accounts.

17. STIG – Database Auditing – cont.
DBA Auditing – IAO ensures that all database connections used to perform the following listed DBA actions are audited
Database startup
Database shutdown
Database online backup
Database archiving
Database performance statistics collection
Value Based Auditing
The DBA will ensure that access and changes to classified data are stored in the DBMS transaction log.
The IAO will ensure that DBMS transaction logs are reviewed weekly or more frequently for suspicious or unauthorized changes to classified data or data stored in a MAC I or MAC II DBMS.
The IAO will ensure that processes or procedures are in place to notify users of the time and date of modifications to classified data stored in the database.
Required Audit Operations on Audit Data
The DBA will ensure that database audit trail information is audited for all update/deletion
The DBA/SA will ensure that all audit data deletion operations cause an audit record to be generated within the active audit trail.
Audit Data Access
The DBA will ensure that access to any DBA views that allow a database account to display audit information is restricted to DBAs or security auditors.
The DBA will ensure that select, insert, delete, or update privileges on audit information is restricted to DBAs or security auditors.
The DBA will ensure that privileges to disable auditing are restricted to DBAs or security auditors
MAC – Mission Assurance Category
Reflects the importance of information
MAC 1 – Systems handling information that is determined to be vital to the operational readiness – most stringent
MAC 2 – Important for the support of deployed and contingency forces
MAC 3 – necessary for the conduct of day-to-day business but does not affect support to deploy forces

18. STIG – DAC – Database Authorizations
Database Object Access (DBA)
Application grants – through Roles
Application object privileges are not granted to PUBLIC.
DBMS default object privileges not granted to PUBLIC unless required by DBMS vendor.
Access to DBA views and tables is restricted to DBAs and batch processing accounts that have been documented with the IAO.
Database Roles (DBA)
Application user roles are granted the most limited set of privileges that allows the user to accomplish the specific job function required of their position.
Roles are not granted to PUBLIC.
No permissions are granted directly to database accounts
DBA Role (DBA)
DBA role is restricted to authorized users only (production and development).
The IAO will authorize all DBA accounts.
Developer Roles (DBA)
Shared production/development host system, an application developer database account is not granted DDL permission on production database.
Shared production/development host system, No OS privileges for developers on production files, directories or database components (DBS & SA)
Privileges assigned to application developer database accounts are justified and authorized by the IAO.
SA, developers are not granted system privileges within a production database.

19. STIG – Database Auditing
Audit Data Requirements
The IAO will ensure that auditing is configured and implemented on all systems.
The DBA will ensure that audit data is captured for all required database events
The SA/DBA will ensure that audit data is captured for database events that are auditable at the host system level including database process or service startup/shutdown and database authentication or access.
The IAO will ensure that database audit data is captured and maintained for one year.
The DBA will ensure that audit data is only readable by personnel authorized by the IAO.
Minimum Required Audit Operations
The DBA will ensure that the creation, alteration, or deletion (drop) of database accounts, system structure, objects, tables, indexes are audited.
The DBA will ensure that enabling and disabling of audit functionality is audited.
The DBA will ensure that granting and revoking of database system level privileges is audited.
The DBA will ensure that any action that returns an error message because the object referenced does not exist is audited.
The DBA will ensure that any action that renames a database object is audited.
The DBA will ensure that any action that grants or revokes object privileges from a database role or database account is audited.
The DBA will ensure that all modifications to the data dictionary or database system configuration are audited.
The DBA will ensure that all database connection failures are audited. Where possible, the DBA will ensure that both successful and unsuccessful connection attempts are audited.
1 year is the benchmark – push back on other requirements

20. STIG – Database Auditing – Audit Data Reviews
General Audit Requirements
The database audit data will be reviewed regularly and within a scheduled time frame.
This review process will check for any intrusive activity and any anomalous activity.
Daily Reviews for the following:
Excessive logon attempt failures by single or multiple database accounts
Logons at unusual/non-duty hours
Failed attempts to access restricted system or data files indicating a possible pattern of deliberate browsing
Unusual or unauthorized activity by System Administrators
Command-line activity by a database account that should not have that capability
System failures or errors
Unusual or suspicious patterns of activity
The DBA or security administrator will do the following:
Provide reports on current audit data
Provide reports on historical audit data
Provide a methodology to back up current audit data into a historical format
Provide a means of archiving current audit data after a backup to a historical format
The IAO will ensure that the database audit data is reviewed daily.
For a daily review you need a dedicated monitoring team

21. STIG – Database Monitoring
In addition to reviewing audit data collections, unauthorized database activity may also be discovered by actively monitoring the status of database objects.
The DBA will monitor the database for unauthorized changes to database objects.
The SA will monitor the file system for unauthorized changes in critical system or database files.
The DBA will monitor database batch and job queues to ensure that no unauthorized jobs are accessing the database.
The DBA will monitor database account expiration and inactivity and remove expired and inactive accounts in accordance with site policy.
The DBA will monitor the database to discover access by unauthorized application software.

22. Top Data Protection Challenges
Where is my sensitive data located & who’s using it?
How can I enforce access & change control policies for critical databases?
How do I check for vulnerabilities and lock-down database configurations?
How do I automate & centralize compliance controls?

23. Database Security, Risk Management & Governance Lifecycle
Discover all databases, applications & clients
Discover & classify sensitive data
Vulnerability assessment
Configuration assessment
Behavioral assessment
Baselining
Configuration lock-down & change tracking
Discover
&
Classify
Assess
&
Harden
Critical Data
Infrastructure
Centralized governance
Compliance reporting
Sign-off management
Automated escalations
Secure audit repository
Data mining for forensics
Long-term retention
100% visibility
Policy-based actions
Anomaly detection
Real-time prevention
Granular access controls
SIEM integration
Monitor encrypted connections (Oracle ASO, SSL, etc.)
Audit
&
Report
Monitor
&
Enforce 23

24. Scalable Multi-tier Architecture First Solution for 100% Visibility Into All Mainframe Database Activity Without Impacting Business Processes
Dell Case Study:
Heterogeneous environment: Oracle & SQL Server, including Oracle RAC and SQL Server clusters, on Windows & Linux, with mix of enterprise applications including Oracle e-Business, JD Edwards, Hyperion and in-house applications. Includes databases supporting 7x24 manufacturing and customer-facing Dell.com site.
Key drivers: SOX, PCI and SAS70
Deployed to ~300 database servers in 10 data centers around the world, over 12 weeks. Using S-TAPs exclusively to monitor traffic.
Previously using: mix of homegrown scripts, native logging and 3rd-party application (BindView), different approaches for Oracle and SQL Server. Lots of work to maintain scripts and keep them running. Oracle system table overflowed and brought down critical database. Frustration because DBAs were working on this rather than deploying new business projects. Struggled to keep with up massive volume of audit data being generated, and present it so that they could pass their audits.
Needed:
-- Minimal overhead.
-- Separation of duties.
-- No changes to databases.
-- Automated audit reporting.
-- Complete visibility into all transactions (DDL, DML, etc.).
-- Real-time, proactive security.
-- Scalability to handle large distributed environment.
-- Integration with Remedy change management system.
Multi-tier architecture;
-- S-TAPs collect data on each DB server.
-- Collectors receive data from multiple S-TAPs.
-- Aggregators in each geography receive data from multiple collectors.
-- Centralized Web console.
Future plans:
-- Expand to additional 725 DB servers
-- VA
-- Application user monitoring
-- CAS

25. Single set of security policies & compliance views for both mainframe & distributed environments
DB2 for Z/OS
Z2000
Z-TAP
DB2 for UNIX, Linux, Windows
G5000 Central Policy Manager & Aggregator
S-TAP
G2000
Oracle, SQL Server, Sybase, Informix
S-TAP

26. Discover & Classify

27. Database auto-discovery
Drill-down

28. Data discovery & classification

29. Assess & Harden

30. Vulnerability & configuration assessment

31. Vulnerability Assessment Score Sheet

32. Behavioral assessment

33. Baseline & Identify anomalous behavior
Automatically suggests rules based on profiling
Prevents unusual activities & attacks such as SQL injection
Merge new policies as environment changes

34. Database configuration “lock down” using CAS
200+ pre-configured knowledge templates for all major OS/DBMS configurations

35. Configuration File change identifies by CAS

36. Monitor & Enforce

37. Enforce with real-time policies

39. Extrusion policies: identify “outbound” sensitive data

40. Audit & Report

41. Application user monitoring

42. Change control reconciliation
Automatically tag all changes with ticket numbers (e.g., Remedy)
Compare changes to authorized work orders
Detect & report on all unauthorized changes
No ticket #’s, outside authorized periods, unauthorized IDs, …

43. Prove Compliance

44. Workflow automation

45. Thank you!