I always tell people we are NOT securing Oracle the database; we are BUT not with that as the primary focus. We are in fact securing DATA. DATA is the focus and what we are aiming to do. When I say "we" I mean you should be thinking this as well.
If, a company just follows a guide from someone else such as the CIS Oracle benchmark then yes, this is supposed to be an industry consensus BUT it doesn't state company X or company Y or your Product A or Product B or your sensitive data Q or sensitive data P. How does this secure YOUR DATA? it doesn't of course. It does help on two levels though; you do something but it doesn't per-se secure YOUR CRITICAL DATA. There is also a side effect of following and implementing something like CIS Oracle benchmark; it gets staff thinking about and implementing some level of security; so this is good BUT what is actually needed to secure YOUR DATA?
I can talk for days about this idea and subject BUT I want to limit this to a shortish post to get people thinking. The goal of any Oracle security project should be to secure DATA not to simply implement an Oracle feature or follow a generic list. Lots of companies spend time and money on functional requirement and performance BUT think about security of data only when its too late
You must have a goal to protect certain data from certain attacks or from certain loss of that data from the system. To do this task we need to briefly consider the following:
- What data are we protecting? - simple but if you don't know what you are protecting then how can you protect it?
- Where is the data we are protecting? - We must know all copies of the data we want to protect. This is in the database and outside of it. If you wish to protect a certain data but that data is extracted from the database and stored on the file system of the database server or other servers or users PC's then no amount of database security will protect that data as I can steal it from elsewhere instead
- How is the data processed? - How does the data get into the database and how does it leave?. For instance end users may enter data via forms in an application and data may leave via extracts though ETL or backups or?? we must know how data flows into and out of the system to be able to secure that data
- Appreciate that Oracle is complex - The database is complex and your applications are complex. Data gets cached or copied and we must know how the data is flowed through Oracle and how it can be accessed via views, tables, dumps
- What existing security policies exist? - Most companies do not have an Oracle specific security policy BUT do usually have an organisation wide security policy. Ensure that those company wide policy rules are reflected in the Oracle database such as password rules.
- Create a data security standard - You cannot secure data randomly but as I stated above we also should not simply just follow a general list as that does not focus on your data security. Create your own standard based on data
- Understand your skills and your budget - There are many ways to get to the same result in Oracle and the same applies to securing data. Plan your counter-measures to secure your data. It is obvious but you can only do what you have time and money and people to do those tasks with. Consider your budget. Spend as little as possible to secure as much data as possible
- Secure the data in the database - If you secure the data in the database, do not let it leave the database otherwise the security in the database pointless.
- Database Access Controls - Only let people directly access the database if there is an absolute need to do so. Do not lets swathes of staff share accounts and access. Use technical controls to prevent un-authorised access
- Least Rights - Ensure every user authorised to access the database has only the privileges necessary to do their work and no more. This includes DBA, support and other users as well.
- Data Access controls - This is the opposite end of the least privilege above except that we instead look from the point of view of the data rather than the user. Ensure that data is only accessible when absolutely necessary and no other times.
- Context based security - When possible use context based security. This can be Oracle products such as VPD, TSDP or Database Vault but can also be home grown with views, triggers and other code. The normal object level security is very granular at the macro level and not at the micro level. We can use context based security to ensure that some specific data is accessed only on Wednesday by Jim between 15:00 and 16:00 and using screen 4 of the application only
- Basic hardening - Do basic hardening such as removing defaults or samples and changing standard settings
- Do secure coding - Ensure that all your applications that access the database and therefore the data are coded to secure coding standards to avoid possible code based attacks such as SQL Injection
- Use audit - Design succinct audit trails that will capture any possible attacks against your database and your data. This audit trail design like the overall security design must be design based and not random. Create audit events that will capture things that should not happen
Wow, that's a brief overview of the key elements that should be considered when securing data that is held in an Oracle database. There are elements missing such as Operating system security and network security that must also be part of the overall plan. We didn't cover encryption of data both at rest, in motion in the database and in-motion across the estate.
Do not consider just buying a security add on until you have designed and built all of the core data security we have briefly covered above. i.e. I like Oracle Database Vault but what is the point of deploying Database Vault out of the box with no core data security or with one or more persons having access to root, oracle, SYSDBA and DV accounts. Also remember security products such as Database Vault are just applications and also should be secured!!
Also worth considering is when an application framework such as APEX is used. In this case we must secure our application code, secure coding, users privileges and more BUT also we must secure APEX itself, its settings and its repository in general and then we must secure the core database that APEX is deployed in.
Hope that this is useful as an overview to what can be involved in securing data in Oracle
#oracleace #23c #dbsec #oracle #database #security
