Database Reference
In-Depth Information
It would be great to remove passwords completely in the future, which is the goal of Cambridge's current
research. However, this research does rely on “something you have, namely PICO, as described at this URL.
I will not suggest that 12c should support McEliece's cryptography and get rid of passwords completely.
Decisions like this depend on the ability to quantify the actual benefit of added security improvements in a
measurable manner as illustrated by this research paper written by my University in London:
In my view, a score of risk advantage compared to usability disadvantage is likely to become more prevalent in
practice. Rules should be followed, such as
“It should not take more than 20 seconds to check out a password from a
break-glass server”
or
“the security configuration of a database server should be implementable in less than 1 hour”
or that
“the encryption hit on data stored on the database should not cause more than a 20% performance hit.”
These SLA-style usability pre-requisites are likely to be included in the design of individual security requirements
in the future.
Oracle may be the most technologically advanced large RDBMS vendor, but the downside to being on the
bleeding edge has been large numbers of patches and thus security risks. This topic will enumerate these risks for 12c
and show how to protect your database against them in the future so that you can have a successful 12c rollout that
does not need to be re-engineered for security afterwards.
Next we are going to have a technical look at how current systems can be defended by adding on your own
defenses and auditing mechanisms. These have been proven in the field so you will be able to deploy quickly to
development and then to production.
