Database Reference
In-Depth Information
General Trends
An organizational trend is for DB security to become embedded in the team of DBAs over time, i.e., ex-DB security
specialists becoming DBAs. This is a good idea, as the team can protect itself rather than depending on a separate
Infosec team. But it should be noted that the bleeding edge evolves quickly, so new specialist DB Infosec people will
be required to keep the DBAs up to date. DBA teams tend to be measured on uptime, efficiency, and performance
rather than absence of security risk. Risk, by nature, is an abstract consideration, much like probability. Just like
car drivers need a separate insurance company, critical infrastructure components need a separate risk function
to calculate and sign off on the risk. An interesting trend in the risk industry is for individual security configuration
parameters to be assigned a specific risk score and for production managers to be given a total maximum allocation
of risk—but with the ability to spend that risk allocation as they see fit. This avoids the common situation of a single
obligatory security configuration breaking a specific application, because the production manager has flexibility
within their system to fix an acceptable percentage of the total configuration issues.
Over the last few years there have been a declining number of software security bugs in the DB code, which has
resulted in fewer and more stable patchsets. However, architectural flaws are still rife, and their presence is becoming
increasingly known. For instance, if we look at the lack of controls on SYS, TNSPoison, stealth brute-forcing, DBlink,
and authentication decryption, we see that these are all design issues that could have been avoided, but once
included in the overall architecture of a system became very difficult to remove, due to the large number of complex
systems that had already been integrated into the design. The use of oradebug is a classic example. The ability for SYS
to turn off its own audit trail still exists in 12c partly because oradebug is so useful for other tasks, such as changing
static parameters without a reboot to preserve uptime. Additionally the lack of security controls on SYS was originally
intended to preserve availability of the admin account, but has been difficult to change after design time. This partly
explains why the design issues have been partly ignored (a.k.a. hidden) while focus has been on selling extra security
features that can be added on, e.g., DB Vault, Audit Vault, TDE, and OPAM. But none of these products enable SYS to
be given the same basic password protections as the other accounts.
Into the Future
On the positive side, the advantage of being an Oracle technologist has been having the privilege of riding on the
crest of new technological waves before our colleagues who are working with other vendors. On that note, I will now
summarize new infosecurity research that will be relevant to future versions of Oracle and hopefully future editions of
this topic. Looking into the future, we can see that multi-party crytography (MPC) is becoming performant enough to
be usable in the enterprise. These two papers describe how MPC is starting to be used in real-world scenarios:
What this means is that two parties can work on shared data without either being privy to that data. Use cases
include the ability for two separate teams, e.g., *nix and Windows SAs, to authenticate each other's passwords without
either having to share their password with the other. Another exciting use case is cloud encryption, as MPC will
allow work to do be done on data without allowing the ability to read it. So the cloud vendor could process your data
without being able to read it. Exciting stuff.
Although quantum computing is speeding up decryption of current encryption algorithms, there are alternative
crypto algorithms that are less susceptible to cracking by quantum computers, e.g., McEliece encryption algorithm as
described here:
