database risk assessment

Aside from security configuration, what else should a risk assessment of databases include, can you provide some input and pointers (specifically oracle RDBMS)?
Who is Participating?
sdstuberConnect With a Mentor Commented:
Security - too many privileges granted.  This, of course, leads to more and easier attack vectors.  However, the biggest problem isn't likely to be malicious behavior but simply human error.  People screw up,  people with elevated privileges will, at some point, do something wrong with an elevated privilege.

Periodically go through the dictionary views for roles and privileges, noting especially roles granted to roles.  Make sure extras haven't made their way in and cascaded through roles to unintended grantees.

Do note though, you can have perfectly assigned privileges and still have a problem.  If my job is to manipulate data then there is a security hole implicit in my responsibilities.  I'm not perfect, so I'm going to make a mistake and when I do I've corrupted the data.   Is that bad? Yes. Is it catastrophic? Maybe, depends on the error, when it happens, where it happens and how long it takes to detect and correct it.

Also, do be aware of potential attackers too.  If your data is worth getting right and worth backing up, it's probably worth something to someone that shouldn't have it too.

Also look at java, XDB, row-level (VPD) and network privileges.
Here are a couple of articles about network ACLs

part1 -
part2 -

Do you have security built into the applications instead of or in addition to database controls?  What happens if/when there is access outside of the application?  What if the application has a bug?

Check new features for each release of Oracle.  Roles change, privileges change, the dictionary changes.  12c introduces a lot of new granular options.

Look at your audit policies; both oracle built in and application instrumentation. Logs and audit records don't add security but they help in tracking breaches and mistakes so corrective action can be taken.

Backups - Your media will fail.  Your network will fail.  You must periodically test your backups and do a restore.  If you can't restore, then your backup is just a storage cost with no value.  Also, think about dependencies.  If feeder system A has a backup retention of one week and consumer system B has a backup retention of 1 year.  What happens when B needs a restore from a month ago and A can't accommodate?

What about applications on top of the databases.  If you restore an old database for version 3 of your software but you're now running version 5, can you still use the data?  

Capacity - capacity is just money and time.  The trending math of of it can be pretty simple; but managing it might not be.  If you need more space and don't have funding, what do you do?  These can be the biggest headache because they aren't technical issues (unless you have a broken process consuming more resources than necessary.)   These need to be in your initial assessment for outages and cost and escalated to the level of whomever pays the bills.    Capacity cost = X, Outage cost = Y.  When Y > X, funding is mandatory.  When X > Y shut the system down.  These aren't threats, they are simple business realities.
Geert GOracle dbaCommented:
well basically that's a very simple calculation

what does it cost if the database is down
what does it cost to prevent the database from being down
Geert GConnect With a Mentor Oracle dbaCommented:
i admit, that may be a little too simple, but that's the bottom line

a comparison:
a database of a car repair shop being down is solved by writing everything on paper
a database of a nuclear power plant being down is solved with a meltdown

all depends on how critical your database is
the measures needed to keep the database up are many
from a single instance database to a mirrored rac database with standby

you could follow this doc for more detailed explanations:

not that a high available database not only relies on the database itself
but can also depend on the building ... an emergency power supply for example
having the electric company switching off the electric usually doesn't help for a HA database
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

if we're setting aside security for this discussion, then the rest of the risk assessment is largely generic, i.e. NOT oracle specific, and not really even database specific.

In addition to cost of "down",  you also need to address cost of "wrong",
What applications and/or people touch the data?  What are checks (and costs of those checks) to ensure the data coming in is reliable?  What are the impacts (and associated costs) if you do get bad data?  What are the costs to fix it?  What is the likelihood of those errors?  A billion dollar fix for an event that doesn't happen is a bad investment.

Also look at interconnectedness.

Is your database a feeder or a consumer or both?
If a feeder, then that effectively means your cost of being down or cost of being wrong is higher because it's not just the cost of getting that database up, it's the cost of fixing everyone downstream from it.

If a consumer, then the risk cost goes up, because even if your system is fully functional, if it's waiting on information from other systems that are down or feeding it bad data then your system is impacted.

If your system sits in the middle as feeder and consumer then you have both concerns.

What are timings of the connections?
If your system is down for an hour in the middle of the day but all of your downstream systems pull from it once a day at midnight, then you're fine as long as you can your fixes in before the pull.  If your downstream systems pull in real time or at some interval faster than you can get a fix then you'll risk and cost go up.

Same thing as a consumer.  If you consume rapidly and frequently then your risk and cost go up as outages or failures occur in your upstream systems.  If you consume slowly and infrequently then you have a buffer to protect you from problems in your source systems.
DavidConnect With a Mentor Senior Oracle Database AdministratorCommented:
The assessment effort per se should include an evaluation of what can go wrong; the statistical chance of that happening; the comparative risk to the ongoing operations; the risks ranked by their impact costs; the determination of which events are acceptable risks; and the mitigation project plan for the balance.
pma111Author Commented:
Thanks for the tips, I was perhaps more after some pointers on the actual common areas that can and do go wrong, i.e. security settings, issues with backups, capacity (i.e. running out of space due to poor management and monitoring) etc.
DavidSenior Oracle Database AdministratorCommented:
That's a great summary; the only thought I might tack on is to think though your processes, your network, etc., looking for redundancy (a good thing).  In other works, find your single points of failure; evaluate them for cost and risk; and get your management on-board to test things.  It is awkward for one's career to show up at a disaster recovery site and discover your recovery plan is broken.
Geert GOracle dbaCommented:
or the recovery site overheating after running for 20 minutes
don't forget an adequate airco !
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.