you have audited our databases, helped us develop baseline security standards and secured our credit card details implementation so we are good to go, we can build new databases to secure standards and we are monitoring and securing our existing databases. When you audited the database and created the baseline and security standards i remember you included things that were already "good" in the systems you reviewed; this made sense to us as building a new secure database or hardening an existing one needs to include items that were also correct. BUT, what about new bad things, new bad practices, how do we prevent bad practices from recurring; shoudl we include a list of "DO NOT DO THIS" in our standards
This is a very interesting point and is of course related to the point in his email. I do security audits of customers Oracle databases and i produce a report detailing all of the issues located in their databases. I don't tend to tell them about the things that were correct mainly due to space/time but if I am employed to write a baseline standard/secure build document I do consider the things that were found to be correct during the audit; this is normal. Should we also include things that "you definitely should not do" BUT we also didnt find in the database that was audited? - I am not sure? The issues located during an audit fall into three groups:
- Security issues located - things that are bad for security
- Security issues not located - things that are bad for security but the database tested was secure in these respects
- Security issued not located - things that are bad for security but were not found in the database (so we were good/secure) but are worst practice and should be avoided
I audit each database for thousands of possible security issues so listing them all in a clients report is not good for space, clarity or my IPR. So the question is should I also include a section in my hardening guides/secure build standards that describes worst practice issues from an Oracle security perspective in each client report so that the client is aware of them at the "point of sale" so to speak; the hardening guide. Its a good idea but I am uncertain as worst practice unless its common worst practice doesnt need to be pointed out to everyone - in case they go and do the worst practices.
So what would fall under Oracle Security Worst Practice? - I have seen some corkers but i need to be prudent about whether i talk about them here. At a general level we can start to list some worst practices from an Oracle security perspective, these are some I can think of just now, I will add more later:
- Don't use built-in sample accounts for business purposes. I have seen sample accounts used for business purposes running parts of applications
- Don't make your DBA's accounts too powerful (this should get reaction!) - I have seen DBA accounts that have ALL PRIVILEGES, SYSDBA, SYSOPER and the DBA role
- Dont allow users (or indeed anyone) to share database accounts - i almost always see evidence of this
- Don't write crazy interfaces that allow any code to be run (like CTXSYTS.DRILOAD.VALIDATE_STMNT) - i see these quite often, they not always easy to find
- Don't write crazy interfaces - I often see back-doors implemented to satisfy some business purpose - like the Java interface that allowed communication to be passed to the listener - With this is was possible to become SYS from inside the database
- Don't wirte crazy code - I often see back doors implemented by sofwtare vendors that allows someone an interface to become the admin in the application
- Work practices often include the idea that the data is best held outside the database - hmmmm - i always find data outside the database, in files, in old databases, in exports......
Thats just a few to get you started.
