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!!