DBSecWorx Secure Configuration
Home / Services / Secure Configuration

      Products Services Industries Resources Relationships About Us
There is often confusion between the responsibilities of different IT group's when creating a secure environment. Let's review them from the standpoint of an Oracle Database.
  • We expect architects to work out design systems and define the components required to build it. Here is a short list of some of the major places where architecture decisions impact database security
    • Integration with network components such as firewalls, VPNs, switches, routers and associated capacity requirements
    • Integration with shared server resources such as NTP, DNS, and DHCP
    • Integration with Identity Management resources such as LDAP and Active Directory, and Multi-Factor Authentication (MFA)
    • Operating System selection
    • Persistent storage requirements such as capacity, IOPS, block versus object storage and how these requirements will be met
    • Server metrics such as chipset, memory, internal drives, and other components
    • Database edition, version, and features subject to licensing
    It is impossible for architects to also be subject matter experts with respect to each of these components during installation and configuration and when they try the outcome is most often the OEM defaults. Architects determine what to purchase but they are not procurement selecting vendors, and they should not determine how the system is installed and configured except at the macro level.
  • Installation
    Anyone that is reasonably competent with vi can install an Oracle Database. Oracle has published step-by-step instructions on the web for years that, if followed, will create a working database based on the templates available via OUI, NETCA, and DBCA. Attackers have been focused on breaking into the databases created with these templates for just as long. Attackers have also read STIGs, Center for Internet Security (CIS) guides, and other published recommendations and are prepared to breach all of them. The published recommendations are the bare minimum to pass an audit. A secure installation requires going beyond the published cookbooks.
  • Configuration
    Security requires Defense-In-Depth which is impossible to achieve unless the decisions made closest to the data are treated with the care they deserve. A secure configuration requires attention to detail. Those details include the following and more
    • SQLNET.ORA, LISTENER.ORA, and TNSNAMES.ORA be fully configured something we essentially never see
    • Oracle's default profile is never assigned to any user
    • One or more customized profiles should be created based on user's roles and responsibilities
    • Oracle's default roles are never assigned to any user
    • Application specific roles should be created based on categories of user's roles and responsibilities
    • Most of Oracle's default grants to PUBLIC are revoked and granted in a secure manner if required
    • DDL and System Event Triggers have been created to bad behavior not just to write a line in an audit file
    • All application and user accounts are created and audited as database proxy users
Will your database refuse access to the wrong person wielding a valid userid and password?
Will your database refuse to let an offshore DBA from data in memory?
If you need to, can you reset every database password immediately without an outage?
Will your database pass a HIPAA, PCI, CIS, NIST, DFARS or other audit?

Improved security rarely requires purchasing expensive licenses. Most of Oracle's customers already have what they need to address their issues within their existing licenses.

At DBSecWorx we can assist you, at every level, to create a more secure environment for your data and your databases. Call us to find how.
- Blog Principles Principals Contact Us
DBSecWorx secures data and databases

 Copyright © 2019-2021
DBSecWorx All rights reserved.
Privacy & Cookies Policy Privacy Shield Legal