In the old days; more than ten years ago there were quite a few people posting Oracle Security blogs but this stagnated and died mostly. I was the first and oldest Oracle security blog and was joined by Alex, David, Slavic, Steve and a few more who would blog regularly on the subject of Oracle Security. Most have stopped almost completely or post such a small amount of posts now and then. There are not really any new people who post about only Oracle security and none that do it exclusively like me. In fact myself and Steve Kost are probably the only regulars still. Some people like Laurent, Dennis, Kamil and Rodrigo Jorge do post on the subject of Oracle security from time to time as do others but there does not seem to be a ground swell of Oracle security posting as there was more than 10 years ago.
I decided to count up and see how my Oracle Security blogging has changed over the years. Here is a graph from 2004 to now.
As you can see i posted a lot in the early days and this curved off as time went on. Why? well there was a golden age of Oracle security when people were starting out to consider the problems and issues in securing Oracle. The start of this coincided with the start of the push for Oracle security patches; the start of finding SQL injection issues in Oracle built in packages and the overall buzz around securing Oracle. This tailed off as did the discussions around why Oracle didn't tell us exactly what was fixed in every CPU; people just got on and moved on. I still blogged but less so as i was just too busy. Now, i am even busier BUT i want to get back to talking about Oracle security in more details again.
The time of data security is now; we have more and more breaches of data, almost daily and two big ones in the last weeks; 500 Million records lost at Marriott (for sure an Oracle database was involved) and Quora forums also had a big breach; We have just had GDPR go live and there is a definite push towards people doing more around Oracle security and data security in general. Just recently Oracle made Privilege analysis free with EE and 18x XE also includes most of the security cost options for free. I discussed this very briefly in my recent post on super locking an Oracle database.
I do plan to post more going forwards on Oracle security. I have a big list of collected subjects that I want to cover here; and i will make it my new years resolution to try and post more. Well thats me and I think its write to talk more about securing Oracle in particular and securing data in general. We are for sure in an era of a heightened need to secure data.
Virtual Patching or Good Security Design instead?
I got an email from someone recently who asked me about virtual patching for Oracle as they were running an out of date version of Oracle and were thinking that virtual patching maybe a good solution to make their database more secure when they cannot get PSU / CPU Security patches for the database. I wrote them a reply and then thought actually this is a good topic for a blog post; so here is my reply a little edited to remove any identity.
Around 10 - 12 years ago a lot of companies were in the virtual patching space (BlueLane, Sentrigo, ....). I always believed this was a non-starter longer term and at best a very limited solution to a very specific problem (i.e. no patches). The problems at a high level are:
1 - Oracle does not publish what it fixes in each CPU (PSU from 12c). It only credits external people who follow their rules and does not credit internal fixes. Mary Ann Davidson the head of security many years ago said (I think in her blog or perhaps it was Eric Maurice; i am not certain now but the point is still valid) external report 20% of issues and internals 80%. So we have no fixed list of whats fixed in a CPU. The tool vendors must reverse engineer every CPU and then develop a check to block an attack. Everything fixed by Oracle has many possible attack vectors. A SQL Injection in a package such as DBMS_METADATA may be exploited to grant DBA to the user BUT it also the attack against the same issue could be completely different. Most of these virtual patch products focus on specific attacks and completely generic attacks are hard to match and detect. Also most of the VP products tended to focus only on remotely exploitable issues
2 - Securing data in an Oracle database falls into a number of grouped activities:
A - hardening and patching (what my emailer wanted to cover); these form a small part of securing data. In general if i can hack and steal card details from your database; then i can probably still do it even if you harden or patch. This is because the patch and the hardening does nothing to secure data; they are general counter-measures
B - Limit access to the database; this can be with simple tools such as firewalls, Oracle listener settings; logon triggers, users password security. This is the number one issue to solve; STOP people connecting to your database. If they cannot connect, they cannot hack or steal data
C - User Access controls; for the users that you do allow to connect then they should have least privilege; i.e. just exactly the right amount of privileges to do their job and no more. In my experience of performing security audits for a very long time for clients people have created the opposite; most privilege design; i.e. no granularity and no respect for what the purpose of a user actually is
D - Data access controls; we must understand where our data is and how its used and then how its secured. We must know who, what, why, when is allowed and design permissions on code and data accordingly. The main problem is that permissions at a table or procedure level are too granular. Therefore we need the next item (E)
E - We should use context based security around access controls to the database, around user rights and around data access controls. This can by use of Oracle VPD, OLS, DV, TSDP and more OR it can be done for free. For instance DV out of the box makes some limited hardening; changes some permissions on DBA, SYS and SYSTEM and creates separation of duties for privileged accounts. We can do a lot of this for free by simple working practice and good database security design; i.e. DV limits the system %ANY% privileges; instead we can not grant them to "our" DBA role; simple! We can seperate security DBA work from OPS DBA work. We can even create controls like realms by use of DML or SYSTEM triggers or by views with functions to control access. Don't just assume that these great products are only available if you have EE or money to license them; we can still simulate some of the "intent" of these products; not as perfect as DV BUT most databases in my experience are not secure anyway so a home grown method + some bits of code is fine; its better than no security; don't get hung up on perfection; security is always a compromise.
F - Finally we should implement a useful, succinct and easy to manage audit trail around all of the above. i.e. not just audit access to key business data but also audit the database engine itself for abuse; for changes to audit, for changes to security and also to detect possible attacks
There are two problems to solve in securing Oracle; 1) hardening & patching and 2) data security design; my experience is that people are not brilliant at both BUT if they have done something then its a nod to patching maybe (and this will not secure your actual data) and a nod to some level of hardening (again in general this will not secure your data). Your money is better spent focusing on the actual problem; securing the data in your database. This is especially pertinent now that we have GDPR!
Using a virtual patch is a short term solution and flawed at best. Even if you cannot patch if you can limit the access to the listener completely and limit database access with controls and data access controls as well then even if you cannot patch it may be better to spend your money wisely on data security design to see if you can create controls on the access and data instead.
How can we help you with this? well in a number of ways:
1 - Scan all of your databases with PFLScan for security issues and understand the security currently implemented in all of your Oracle databases
2 - We provide a SAAS for help implementing a useful easy to manage audit trail in your databases. This is called PFCLATK. Currently this is a service based on us helping you design an audit plan and policy and map all of the events that you would like to capture and extended with events that we think that you should capture. We then help you implement this as a set of audit trail policies and events in your databases.
3 - We have lots of expert level training classes taught by me aimed at helping people secure your data in Oracle databases
Contact me to book a service or a training place or to see a demo of our products or to discuss how we can help you secure the data held in your Oracle database.
Talk to me if you want more details!!
Around 10 - 12 years ago a lot of companies were in the virtual patching space (BlueLane, Sentrigo, ....). I always believed this was a non-starter longer term and at best a very limited solution to a very specific problem (i.e. no patches). The problems at a high level are:
1 - Oracle does not publish what it fixes in each CPU (PSU from 12c). It only credits external people who follow their rules and does not credit internal fixes. Mary Ann Davidson the head of security many years ago said (I think in her blog or perhaps it was Eric Maurice; i am not certain now but the point is still valid) external report 20% of issues and internals 80%. So we have no fixed list of whats fixed in a CPU. The tool vendors must reverse engineer every CPU and then develop a check to block an attack. Everything fixed by Oracle has many possible attack vectors. A SQL Injection in a package such as DBMS_METADATA may be exploited to grant DBA to the user BUT it also the attack against the same issue could be completely different. Most of these virtual patch products focus on specific attacks and completely generic attacks are hard to match and detect. Also most of the VP products tended to focus only on remotely exploitable issues
2 - Securing data in an Oracle database falls into a number of grouped activities:
A - hardening and patching (what my emailer wanted to cover); these form a small part of securing data. In general if i can hack and steal card details from your database; then i can probably still do it even if you harden or patch. This is because the patch and the hardening does nothing to secure data; they are general counter-measures
B - Limit access to the database; this can be with simple tools such as firewalls, Oracle listener settings; logon triggers, users password security. This is the number one issue to solve; STOP people connecting to your database. If they cannot connect, they cannot hack or steal data
C - User Access controls; for the users that you do allow to connect then they should have least privilege; i.e. just exactly the right amount of privileges to do their job and no more. In my experience of performing security audits for a very long time for clients people have created the opposite; most privilege design; i.e. no granularity and no respect for what the purpose of a user actually is
D - Data access controls; we must understand where our data is and how its used and then how its secured. We must know who, what, why, when is allowed and design permissions on code and data accordingly. The main problem is that permissions at a table or procedure level are too granular. Therefore we need the next item (E)
E - We should use context based security around access controls to the database, around user rights and around data access controls. This can by use of Oracle VPD, OLS, DV, TSDP and more OR it can be done for free. For instance DV out of the box makes some limited hardening; changes some permissions on DBA, SYS and SYSTEM and creates separation of duties for privileged accounts. We can do a lot of this for free by simple working practice and good database security design; i.e. DV limits the system %ANY% privileges; instead we can not grant them to "our" DBA role; simple! We can seperate security DBA work from OPS DBA work. We can even create controls like realms by use of DML or SYSTEM triggers or by views with functions to control access. Don't just assume that these great products are only available if you have EE or money to license them; we can still simulate some of the "intent" of these products; not as perfect as DV BUT most databases in my experience are not secure anyway so a home grown method + some bits of code is fine; its better than no security; don't get hung up on perfection; security is always a compromise.
F - Finally we should implement a useful, succinct and easy to manage audit trail around all of the above. i.e. not just audit access to key business data but also audit the database engine itself for abuse; for changes to audit, for changes to security and also to detect possible attacks
There are two problems to solve in securing Oracle; 1) hardening & patching and 2) data security design; my experience is that people are not brilliant at both BUT if they have done something then its a nod to patching maybe (and this will not secure your actual data) and a nod to some level of hardening (again in general this will not secure your data). Your money is better spent focusing on the actual problem; securing the data in your database. This is especially pertinent now that we have GDPR!
Using a virtual patch is a short term solution and flawed at best. Even if you cannot patch if you can limit the access to the listener completely and limit database access with controls and data access controls as well then even if you cannot patch it may be better to spend your money wisely on data security design to see if you can create controls on the access and data instead.
How can we help you with this? well in a number of ways:
1 - Scan all of your databases with PFLScan for security issues and understand the security currently implemented in all of your Oracle databases
2 - We provide a SAAS for help implementing a useful easy to manage audit trail in your databases. This is called PFCLATK. Currently this is a service based on us helping you design an audit plan and policy and map all of the events that you would like to capture and extended with events that we think that you should capture. We then help you implement this as a set of audit trail policies and events in your databases.
3 - We have lots of expert level training classes taught by me aimed at helping people secure your data in Oracle databases
Contact me to book a service or a training place or to see a demo of our products or to discuss how we can help you secure the data held in your Oracle database.
Talk to me if you want more details!!
