I assume from your comment that when a user is created by default he gets the access to all the required data dictionary tables. No explisit GRANT is made for that.

ops$tkyte%ORA10GR2> select * from dba_tab_privs where grantee = 'PUBLIC';

GRANTEE                        OWNER
------------------------------ ------------------------------
TABLE_NAME                     GRANTOR
------------------------------ ------------------------------
PRIVILEGE                                GRA HIE
---------------------------------------- --- ---
PUBLIC                         SYS
DUAL                           SYS
SELECT                                   YES NO

PUBLIC                         SYS
SYSTEM_PRIVILEGE_MAP           SYS
SELECT                                   YES NO
....

ops$tkyte%ORA10GR2> select substr( table_name, 1, 4 ), count(*)
  2  from dba_tab_privs
  3  where substr( table_name, 1, 4 ) in ( 'ALL_', 'USER' )
  4  group by substr( table_name, 1, 4 );

SUBS   COUNT(*)
---- ----------
ALL_        329
USER        376

Tom -
one of our production DBAs has just built a new database on which we're going to be storing credit card details and thus has to meet the security criteria of the "Payment Card Industry" (PCI).
One of the things he's done to "secure" the database is revoke PUBLIC access from the ALL_ views.

He cites the following websites (none of them official Oracle sites) as his guides for this action, and also claims these sites ".. are the industry standards for securing Oracle".

http://www.cisecurity.org/bench_oracle.html
http://www.sans.org/score/oraclechecklist.php
http://iase.disa.mil/stigs/stig/index.html
www.petefinnigan.com

Is there any justification in what he's done? I think that fiddling around like this is a recipe for disaster.

I've been through PCI data security requirements for our company. It is ludicrously complex and will require far more than just obscuring views.

We have come to the decision that we simply will not be storing credit card info. My hunch is that is exactly how they want you to respond.

Tom - thanks for your earlier reply.

Our dba has provided the following quote from one of the documents as his justification for revoking public access to the ALL_ views :

As an example, the ALL_USERS view is accessible to PUBLIC and it lists the username of every database schema. A technique often used by hackers is to obtain and use a list of valid user accounts to try to access those accounts. Privileged database option schemas (such as MDYS), default application accounts, and user accounts will be listed by the ALL_USERS view as valid targets to a nefarious user. The list of valid database users then becomes a list of valid database targets. A malicious user could easily say, “Oh look, the <insert option name or your application here> is installed. Let me use the default password and try to access this privileged account.” 
Therefore, you should consider revoking PUBLIC access to certain database metadata. Looking at SYS objects that start with ALL is a good place to start: 

He's clearly interpreted the last couple of sentences as meaning revoke public access from everything prefixed ALL.
I've passed your earlier comments on to him.

ops$tkyte%ORA11GR1> select table_name from all_tab_columns where column_name = 'OWNER' and table_name like 'ALL\_%' escape '\';

TABLE_NAME
------------------------------
ALL_SDO_MAPS
ALL_SDO_GEOM_METADATA
ALL_SDO_THEMES
...
ALL_LOG_GROUP_COLUMNS
ALL_PLSQL_OBJECT_SETTINGS
ALL_CUBE_VIEWS

243 rows selected.

I can see where the recommendation is trying to get to though. Say you had an app connecting in that turned out to be vulnerable to SQL Injection. Yep it’s a bad app that needs fixing but these things seem to raise their head all too frequently.

If the app connects using a separate user from the schema holding your data (as it should) then the default grants of the ALL views to PUBLIC makes it real easy for the attacker to get a good idea of your data model and what privileges the application has on the tables.

Your right though, ALL_USERS by itself it isn’t enough, as your examples show it would need a revoke of most of the ALL views, USER_TAB_PRIVS_RECD as well (and maybe others) to get to a point where someone exploiting a SQL injection loophole is left sitting there scratching their head trying to randomly guess what the schema holding your data is called and what you’ve named your tables.

I wonder if Oracle has ever considered some form of fine-grained revocation, something where if something is granted to PUBLIC it could be revoked for a particular user (a revoke getting stored and overriding the grant rather than just removing a grant as happens as it is), that way you could lock down the application login accounts with a lot more control.

Leaving technology aside though I suspect as with all these things it’s pushed by the external regulators in whatever industry your business happens to be in and ends up being a box-ticking exercise, the regulators want you to prove that you’ve hardened your dbs in order to be compliant. They need some way of standardising and measuring that so they just say implement SANS, CIS or <flavour of the month>...

In the case of my database though, I use 3 separate accounts : one for the PL/SQL packages, one for the tables and one for the application connection. The app-connection account only has access to the packages; it has no grants on any of the tables. Therefore anyone connecting as the app-conn account would see nothing in the ALL_% views relating to the database tables. Surely this would therefore make it unnecessary to revoke public access from the ALL_% views?