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. |
|