File Integrity Monitoring – Database Security Hardening Basics
[ad_1]
The Database – The Mother Lode of Sensitive Data
Being the heart of any corporate application means your database technology must be implemented and configured for maximum security. Whilst the desire to ‘get the database as secure as possible’ appears to be a clear objective, what does ‘secure as possible’ mean?
Whether you use Oracle 10g, Oracle 11g, DB2, Microsoft SQL Server, or even MySQL or PostgreSQL, a contemporary database is at least as complex as any modern server operation system. The database system will comprise a whole range of configuration parameters, each with security implications, including:
- User accounts and password settings
- Roles and assigned privileges
- File/object permissions
- Schema structure
- Auditing functions
- Networking capabilities
- Other security defense settings, for example, use of encryption
Hardened Build Standard for Oracle, SQL Server, DB2 and others
Therefore, just as with any Windows or Linux OS, there is a need to derive a hardened build standard for the database. This security policy or hardened build standard will be derived from collected best practices in security configuration and vulnerability mitigation/remediation, and just as with an operating system, the hardening checklist will comprise hundreds of settings to check and set for the database.
Depending on the scale of your organization, you may then need hardening checklists for Oracle 10g, Oracle 11g, SQL Server, DB2, PostgreSQL and MySQL, and maybe other database systems besides.
Automated Compliance Auditing for Database Systems
Potentially, there will be a requirement to verify that all databases are compliant with your hardened build standard involving hundreds of checks for hundreds of database systems, so automation is essential, not least because the hardening checklists are complex and time-consuming to verify. There is also somewhat of a conflict to manage in as much as the user performing the checklist tests will necessarily require administrator privileges to do so. So in order to verify that the database is secure, you potentially need to loosen security by granting admin rights to the user carrying out the audit. This provides a further driver to moving the audit function to a secure and automated tool.
In fact, given that security settings could be changed at any time by any user with privileges to do so, verifying compliance with the hardened build standard should also become a regular task. Whilst a formal compliance audit might be conducted once a year, guaranteeing security 365 days a year requires automated tracking of security settings, providing continuous reassurance that sensitive data is being protected.
Insider Threat and Malware Protection for Oracle and SQL Server Database Systems
Finally, there is also the threat of malware and insider threats to consider. A trusted developer will naturally have access to system and application files, as well as the database and its filesystem. Governance of the integrity of configuration and system files is essential in order to identify malware or an insider-generated application ‘backdoor’. Part of the answer is to operate tight scrutiny of the change management processes for the organization, but automated file integrity monitoring is also essential if disguised Trojans, zero day malware or modified bespoke application files are to be detected.
File Integrity Monitoring – A Universal Solution to Hardening Database Systems
In summary, the most comprehensive measure to securing a database system is to use automated file integrity monitoring. File integrity monitoring or FIM technology serves to analyze configuration files and settings, both for vulnerabilities and for compliance with a security best practices-based hardened-build standard.
The FIM approach is ideal, as it is provides a snapshot audit capability for any database, providing an audit report within a few seconds, showing where security can be improved. This not only automates the process, making a wide-scale estate audit simple, but also de-skills the hardening exercise to an extent. Since the best practice knowledge of how to identify vulnerabilities and also which files need to be inspected is stored within the FIM tool report, the user can get an expert assessment of their database security without needing to fully research and interpret hardening checklist materials.
Finally, file integrity monitoring will also identify Trojans and zero-day malware that may have infected the database system, and also any unauthorized application changes that may introduce security weaknesses.
Of course, any good FIM tool will also provide file integrity monitoring functions to Windows, Linux and Unix servers as well as firewalls and other network devices, performing the same malware detection and hardening audit reporting as described for database systems.
For fundamentally secure IT systems, FIM is still the best technology to use.
[ad_2]
Source by Mark Kedgley