U DB Oracle11 v8r1.8 Checklist 20100827 PDF

VL05
Page 1 of 130
For Official Use Only

When this document is printed, the document needs to be stamped top and bottom with the appropriate classification.
VL05 - Checklist Report

Unclassified UNTIL FILLED IN
CIRCLE ONE
FOR OFFICIAL USE ONLY (mark each page)
CONFIDENTIAL and SECRET (mark each page and each finding)
Classification is based on classification of system reviewed:
Unclassified System = FOUO Checklist
Confidential System = CONFIDENTIAL Checklist
Secret System = SECRET Checklist
Top Secret System = SECRET Checklist
Checklist: Oracle Databases 11g
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0005683
DG0004
8
Active
DBMS application object owner accounts
Application object owner accounts should be disabled when not performing installation or
maintenance actions.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Oracle Databases 11g (Target: Oracle Databases 11g)
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
I - Mission Critical
II - Mission Support
III - Administrative
Public
STIG ID:
Severity:
Severity
Override
Guidance:
DG0004-ORACLE11
Category II
https://vms.disa.mil/VL05.aspx
8/19/2010
VL05
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Page 2 of 130
Object ownership provides all database object permissions to the owned object. Access to the
application object owner accounts requires special protection to prevent unauthorized access and
use of the object ownership privileges. In addition to the high privileges to application objects
assigned to this account, it is also an account that, by definition, is not accessed interactively
except for application installation and maintenance. This reduced access to the account means that
unauthorized access to the account could go undetected. To help protect the account, it should be
enabled only when access is required.
Application object owner accounts are not disabled.
Yes
Review the object owner accounts as generated. Confirm the account(s) are documented,
authorized to remain enabled and accept as Documentable in VMS.
Database Administrator
Chairman of the Joint Chiefs of Staff Manual (CJCSM) 6510.01, Defense-in-Depth: Information
Assuran App. A, Enclosure A, Para.5.b (8)
Department of Defense (DOD) Directive 8500.1, Information Assurance Para 4.18
Department of Defense (DOD) Instruction 8500.2, Information Assurance (IA) Implementation
ECLP-1
DB-DG0004-ORACLE11 (Script)
From SQL*Plus (NOTE: The owner list below is a short list of all possible default Oracle accounts):
select distinct owner from dba_objects, dba_users
where owner not in
('ANONYMOUS','AURORA$JIS$UTILITY$',
'AURORA$ORB$UNAUTHENTICATED','CTXSYS','DBSNMP','DIP','DVF',
'DVSYS','EXFSYS','LBACSYS','MDDATA','MDSYS','MGMT_VIEW','ODM',
'ODM_MTR','OLAPSYS','ORDPLUGINS','ORDSYS','OSE$HTTP$ADMIN',
'OUTLN','PERFSTAT','PUBLIC','REPADMIN','RMAN',
'SI_INFORMTN_SCHEMA','SYS','SYSMAN','SYSTEM','TRACESVR',
'TSMSYS','WK_TEST','WKPROXY','WKSYS','WKUSER','WMSYS','XDB')
and owner in (select distinct owner from dba_objects where object_type <> 'SYNONYM')
and owner = username
and upper(account_status) not like '%LOCKED%';
To obtain a list of users assigned DBA privileges.
From SQL*Plus:
select grantee from dba_role_privs where granted_role = DBA;
If any records are returned, then verify the account is an authorized application object owner
account or a default account installed to support an Oracle product.
Verify that any objects owned by custom DBA accounts are for the personal use of that DBA.
If any objects are used to support applications or any functions other than DBA functions, this is a
Finding.
Any unauthorized object owner accounts are not a finding under this check as they are noted as
findings under check DG0008.
Any other accounts listed are a Finding.
Fixes:
DB-DG0004-ORACLE11 (Manual)
Disable any application object owner accounts.
From SQL*Plus:
alter user [username] account lock;
Enable application object owner accounts only for installation and maintenance.
DBA are special purpose accounts and do not require disabling although they may own objects.
8/19/2010
VL05
Page 3 of 130
For application objects that require routine maintenance, e.g. index objects, to maintain
performance, consider allowing a special purpose account to own the index or enable the
application owner account for the duration of the routine maintenance function only.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015607
DG0008
4
Active
DBMS application object ownership
Application objects should be owned by accounts authorized for ownership.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0008-ORACLE11
Category II
Database object ownership implies full privileges to the owned object including the privilege to
assign access to the owned objects to other subjects. Unmanaged or uncontrolled ownership of
objects can lead to unauthorized object grants and alterations.
Application objects are owned by accounts not authorized for ownership.
Yes
authorized to own database objects and accept as Documentable in VMS.
ECLP-1
select distinct owner from dba_objects
where owner not in
'AURORA$ORB$UNAUTHENTICATED',
'CTXSYS','DBSNMP','DIP','DVF','DVSYS',
8/19/2010
VL05
Page 4 of 130
'EXFSYS','LBACSYS','MDDATA',
'MDSYS','MGMT_VIEW','ODM','ODM_MTR',
'OLAPSYS','ORDPLUGINS', 'ORDSYS',
'OSE$HTTP$ADMIN','OUTLN','PERFSTAT',
'PUBLIC','REPADMIN','RMAN','SI_INFORMTN_SCHEMA',
'SYS','SYSMAN','SYSTEM','TRACESVR',
'TSMSYSWK_TEST','WKPROXY','WKSYS',
'WKUSER','WMSYS','XDB')
and owner not in
(select grantee from dba_role_privs where granted_role='DBA');
If any records are returned, then confirm that any database object owner accounts listed are
application owner accounts authorized by the IAO. If any are not, this is a Finding.
NOTE: Confirmed default Oracle accounts returned by the SQL statement above should be
considered a false positive. See Oracle MetaLink Note 160861.1 for a current list of default
accounts.
NOTE: Some applications may be designed to require users to create temporary tables during
application execution. This design is not considered good security practice and results in a
Finding for unauthorized application object owners as application user accounts are not allowed to
have system privileges assigned (CREATE TABLE, etc.) nor allowed to own objects in the
database. One possible suggestion for resolving this issue is to have the application object owner
create a static table for user temporary data storage. All users would share the same table.
Fixes:
Document all authorized application object owner accounts.
Use only authorized application object owner accounts to install and maintain application
database objects.
Revoke privileges to create, drop, replace or alter application objects from unauthorized
application object owners.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015609
DG0014
5
Active
DBMS demonstration and sample databases
Default demonstration and sample database objects and applications should be removed.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
8/19/2010
VL05
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Page 5 of 130
DG0014-ORACLE11
Category II
Demonstration and sample database objects and applications present publicly known attack
points for malicious users. These demonstration and sample objects are meant to provide simple
examples of coding specific functions and are not developed to prevent vulnerabilities from being
introduced to the DBMS and host system.
Default demonstration and sample database objects and applications have not been removed.
Yes
authorized to remain and accept as Documentable in VMS.
DCFA-1
From SQL*Plus:
select username from dba_users where username in
('ALLUSERS', 'AOLDEMO', 'AQDEMO', 'AQJAVA', 'AQUSER',
'AUC_GUEST', 'BI', 'CTXDEMO', 'DEMO8', 'DEV2000_DEMOS',
'HR', 'IX', 'OE', 'ORABAMSAMPLES', 'PM', 'PORTAL_DEMO',
'PORTAL30_DEMO', 'QS', 'SCOTT', 'SECDEMO', 'SH',
'WK_TEST')
or username like 'QS_%';
If any usernames are listed and are not documented in the System Security Plan and authorized
by the IAO, this is a Finding.
See MetaLink note 160861.1 for a list of Oracle database users and usages.
Fixes:
For the sample applications and schemas with the Oracle database installation, use the provided
SQL scripts (if present) to remove the application objects and drop the demo users and schemas:
From SQL*Plus:
-- Human Resources application:
@?/demo/schema/human_resources.hr_drop.sql
-- Order Entry application:
@?/demo/schema/order_entry/oe_drop.sql and oc_drop.sql
-- Product Media application:
@?/demo/schema/product_media/pm_drop.sql
-- Information Exchange application:
@?/demo/schema/information_exchange/ix_drop.sql
-- Sales History application:
@?/demo/schema/sales_history/sh_drop.sql
For other demo applications, deinstall using the SQL command:
drop user [demo username] cascade;
Vulnerability Key: V0003727

STIG ID:
DG0015
8/19/2010
VL05
Page 6 of 130
Release Number: 11
Status:
Active
Short Name:
DBMS data definition language use
Database applications should be restricted from using static DDL statements to modify the
Long Name:
application schema.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0015-ORACLE11
Category III
Application users by definition and job function require only the permissions to manipulate data
within database objects and execute procedures within the database. The statements used to
define objects in the database are referred to as Data Definition Language (DDL) statements and
include the CREATE, DROP, and ALTER object statements (DDL statements do not include
CREATE USER, DROP USER, or ALTER USER actions). This requirement is included here as a
production system would by definition not support changes to the data definitions. Where object
creation is an indirect result of DBMS operation or dynamic object structures are required by the
application function as is found in some object-oriented DBMS applications, this restriction does not
apply. Re-use of static data structures to recreate temporary data objects are not exempted.
Database applications are not restricted from using static DDL statements to modify the application
schema.
Yes
Review the object owner accounts, creation dates and objects as generated. Confirm the objects
are documented, authorized to remain and accept as Documentable in VMS.
Information Assurance Officer
ECSD-1, ECSD-2
If the database being reviewed is not a production database, this check is Not a Finding.
select created, owner, object_name, object_type
from dba_objects
where owner not in
('SYS', 'SYSTEM', 'ORDSYS', 'XDB', 'OLAPSYS', 'ODM')
and object_type <> 'SYNONYM'
8/19/2010
VL05
Page 7 of 130
order by created, owner, object_name;

View the list of objects retuned.
If any object-creation dates do not coincide with the software maintenance and upgrade logs or
are not objects documented as supporting dynamic object creation functions, then investigate the
circumstances under which the object was created.
If the object is created using static definitions to store temporary data or indicates that the
application uses unauthorized DDL statements, this is a Finding.
Fixes:
Document known object creation that supports dynamic object assignment in the System Security
Plan and authorize with the IAO.
Coordinate with the application designer to modify the application to use static objects with
temporary data rather than using temporary objects.
You may use the following code to periodically monitor for recently created objects:
select created, owner, object_name, object_type
from dba_objects
where owner not in
('SYS', 'SYSTEM', 'ORDSYS', 'XDB', 'OLAPSYS', 'ODM')
and object_type <> 'SYNONYM'
and created >= sysdate-30 -- Lists objects created within last 30 days
order by created, owner, object_name;
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0005685
DG0029
8
Active
Database auditing
Required auditing parameters for database auditing should be set.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
DG0029-ORACLE11
Category II
8/19/2010
VL05
Page 8 of 130
Vulnerability
Discussion:
Oracle auditing can be set to log audit data to the database or operating system files. Logging
events to the database prevents operating system users from viewing the data, while logging
events to operating system files prevents malicious database users from accessing the data.
The value NONE disables auditing and is, therefore, not in compliance with policy.
Default Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Required auditing parameters for database auditing are not set.

No
ECAR-1, ECAR-2, ECAR-3
From SQL*Plus:
select value from v$parameter where name = 'audit_trail';
If the value returned is NONE, this is a Finding.
Fixes:
Enable database auditing.
Select the desired audit trail format (external file or internal database table).
From SQL*Plus:
alter system set audit_trail= [audit trail format] scope=spfile;
Compliant selections for [audit trail format] are (per MetaLink Note 30690.1):
Oracle 11.1 11.2
Oracle 11.1 11.2
= 'true', 'os' & 'db' (true = os for backward compatibility)

= 'db_extended', 'xml' & 'xml, extended'
The above SQL*Plus command will set the parameter to take effect at next system startup.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0002507
DG0030
10
Active
DBMS audit data maintenance
Audit trail data should be retained for one year.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
8/19/2010
VL05
Page 9 of 130
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DG0030-ORACLE11
Category II
Without preservation, a complete discovery of an attack or suspicious activity may not be

determined. DBMS audit data also contributes to the complete investigation of unauthorized
activity and needs to be included in audit retention plans and procedures.
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Audit trail data is not retained for one year.

No
ECRR-1
Review and verify the implementation of an audit trail retention policy.
Verify that audit data is maintained for a minimum of one year.
If audit data is not maintained for a minimum of one year, this is a Finding.
Fixes:
Develop, document and implement an audit retention policy and procedures.
It is recommended that the most recent thirty days of audit logs remain available online.
After thirty days, the audit logs may be maintained offline.
Online maintenance provides for a more timely capability and inclination to investigate suspicious
activity.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015133
DG0031
9
Active
DBMS audit of changes to data
Transaction logs should be periodically reviewed for unauthorized modification of data. Users should
be notified of time and date of the last change in data content.
Comments:
Not a Finding
Not Applicable
Not Reviewed
8/19/2010
VL05
Condition:
Page 10 of 130
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0031-ORACLE11
Category II
Unauthorized or malicious changes to data compromise the integrity and usefulness of the data.
Auditing changes to data supports accountability and non-repudiation. Auditing changes to data
may be provided by the application accessing the DBMS or may depend upon the DBMS auditing
functions. When DBMS auditing is used, the DBA is responsible for ensuring the auditing
configuration meets the application design requirements.
Transaction logs are not periodically reviewed for unauthorized modification of data. Users are not
notified of time and date of the last change in data content.
No
ECCD-2
DB-DG0031-2-ORACLE11 (Interview)
If the application does not require auditing using DBMS features, this check is Not Applicable.
Review the application System Security Plan for requirements for database configuration for
auditing changes to application data.
If the application requires DBMS auditing for changes to data, review the database audit
configuration against the application requirement. If the auditing does not comply with the
requirement, this is a Finding.
Review policy and procedures for reviewing access and changes to data.
If policy and procedures are not in place, this is a Finding.
If access and changes to data are not periodically reviewed or immediately reviewed on system
security events, this is a Finding.
If mechanisms are not in place to notify users of time and date of the last change in data content,
this is a Finding.
Fixes:
DB-DG0031-2-ORACLE11 (Manual)
Configure database data auditing to comply with the requirements of the application.
Document auditing requirements in the System Security Plan.
Develop, document and implement policy and procedures for reviewing access and changes to
8/19/2010
VL05
Page 11 of 130
data periodically or immediately upon system security events.

Develop, document and implement mechanisms to notify users of time and date of the last
change in data content.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0031-ORACLE11
Category II
Unauthorized or malicious changes to data compromise the integrity and usefulness of the data.
Auditing changes to data supports accountability and non-repudiation. Auditing changes to data
may be provided by the application accessing the DBMS or may depend upon the DBMS auditing
functions. When DBMS auditing is used, the DBA is responsible for ensuring the auditing
configuration meets the application design requirements.
Transaction logs are not periodically reviewed for unauthorized modification of data.
No
ECCD-1
DB-DG0031-1-ORACLE11 (Interview)
If the application does not require auditing using DBMS features, this check is Not Applicable.
Review the application System Security Plan for requirements for database configuration for
auditing changes to application data.
If the application requires DBMS auditing for changes to data, review the database audit
configuration against the application requirement. If the auditing does not comply with the
Fixes:
Configure database data auditing to comply with the requirements of the application.
Document auditing requirements in the System Security Plan.
8/19/2010
VL05
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
Page 12 of 130
V0005686
DG0032
10
Active
DBMS audit record access
Audit records should be restricted to authorized individuals.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0032-ORACLE11
Category II
Audit data is frequently targeted by malicious users as it can provide a means to detect their
activity. The protection of the audit trail data is of special concern and requires restrictions to allow
only the auditor and DBMS backup, recovery, and maintenance users access to it.
Audit records are not restricted to authorized individuals.
Yes
Review the accounts granted access to the AUD$ table as generated. Confirm the account(s) are
documented, authorized and accept as Documentable in VMS.
ECTP-1
From SQL*Plus:
select value from v$parameter where name='audit_trail';
If none of the following values is displayed, this check is Not a Finding.
Oracle 11.1 11.2
Oracle 11.1 11.2
= 'db'
= 'db_extended'
Review access granted to the AUD$ table.

From SQL*Plus:
select grantee from dba_tab_privs
8/19/2010
VL05
Page 13 of 130
where table_name = 'AUD$'

and grantee not in ('DELETE_CATALOG_ROLE')
and grantee not in
(select grantee from dba_role_privs
where granted_role = 'DBA')
order by grantee;
View access granted to the AUD$ table against those authorized in the System Security Plan.
If any are not authorized, this is a Finding.
Fixes:
Document and authorize accounts granted access to the AUD$ table in the System Security Plan.
Revoke access permissions granted to the AUD$ table from unauthorized users.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0002424
DG0060
10
Active
DBMS shared account authorization
All database non-interactive, n-tier connection, and shared accounts that exist should be
documented and approved by the IAO.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DG0060-ORACLE11
Category II
Group authentication does not provide individual accountability for actions taken on the DBMS or
data. Whenever a single database account is used to connect to the database, a secondary
authentication method that provides individual account ability is required. This scenario most
frequently occurs when an externally hosted application authenticates individual users to the
application and the application uses a single account to retrieve or update database information on
behalf of the individual users.
Default
Database non-interactive, n-tier connection, and shared accounts exist and are not documented or
Finding
approved by the IAO.
Details:
Documentable: No
8/19/2010
VL05
Page 14 of 130
Documentable
Explanation:
Responsibility: Database Administrator
References:
IAGA-1
Database Security Technical Implementation Guide 3.2.1
Checks:
From SQL*Plus:
select username from dba_users order by username;
Review the list of database account names to determine usage of all non-standard account
names or account names that do not appear to be assigned to individuals.
For example, accounts named BATCHJOB, FMAPP, FMAPP-ADMIN do not have the appearance
of assignment to an individual interactive user.
An account name like JDOE appears to be assigned to an individual.
Review the list of account names against those listed in the System Security Plan or authorized
user list.
Consult the IAO or DBA to make a final determination on whether accounts are shared accounts
or not.
If shared accounts are not documented as such and are not approved, this is a Finding.
Fixes:
Use accounts assigned to individual users where feasible.
Design applications to provide individual accountability (audit logs) for actions performed under a
single database account.
Implement other DBMS automated procedures that provide individual accountability.
Where appropriate, implement manual procedures to use manual logs and monitor entries against
account usage to ensure procedures are followed.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0003810
DG0065
9
Active
DBMS PKI authentication
DBMS authentication should require use of a DoD PKI certificate.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
8/19/2010
VL05
Page 15 of 130
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0065-ORACLE11
Category II
In a properly configured DBMS, access controls defined for data access and DBMS management
actions are assigned based on the user identity and job function. Unauthenticated or falsely
authenticated access leads directly to the potential unauthorized access, misuse and lost
accountability of data and activities within the DBMS. Use of PKI certificates for authentication to
the DBMS provides a robust mechanism to ensure identity to authorize access to the DBMS.
DBMS authentication does not require use of a DoD PKI certificate.
No

IATS-1, IATS-2
DB-DG0065-ORACLE11 (Interview)
If user access to the DBMS is via a portal or mid-tier system or product and PKI-authentication
occurs at the portal/mid-tier, this check is Not a Finding.
Review the list of all DBMS accounts and their authentication methods.
This list is usually available from a system view or table and is easily gained from a simple SQL
query.
If any accounts are listed with an authentication method other than a PKI certificate, this is a
Finding.
For MAC 3 systems, if identification and authentication is not accomplished using the DoD PKI
Class 3 certificate and hardware security token (when available) at minimum, this is a Finding.
For MAC 1 and 2 systems, if identification and authentication is not accomplished using the DoD
PKI Class 3 or 4 certificate and hardware security token (when available) or an NSA-certified
product at minimum, this is a Finding.
Fixes:
Implement PKI authentication for all accounts defined within the database where applicable.
Applications may use host system (server) certificates to authenticate.
For MAC 3 systems, use of the DoD PKI Class 3 certificate and hardware security token (when
available) at minimum is required.
For MAC 1 and 2 systems, use of the DoD PKI Class 3 or 4 certificate and hardware security
token (when available) or an NSA-certified product at minimum is required.
8/19/2010
VL05
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
Page 16 of 130
V0002508
DG0070
10
Active
DBMS user account authorization
Unauthorized user accounts should not exist.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0070-ORACLE11
Category II
Unauthorized user accounts provide unauthorized access to the database and may allow access to
database objects. Only authorized users should be granted database accounts.
Unauthorized user accounts exist.
No
IAAC-1
Review procedures for ensuring authorization of new or re-assigned DBMS user accounts.
Requests for user account access to the DBMS should include documented approval by an
authorized requestor.
Procedures should also include notification for a change in status, particularly cause for
revocation of account access, to any DBMS accounts.
Review the user accounts listed either in the script report or manually against the authorized user
list.
From SQL*Plus:
select username from dba_users order by username;
8/19/2010
VL05
Page 17 of 130
If procedures for DBMS user account authorization are incomplete or not implemented, this is a
Finding.
If any accounts listed are not clearly authorized, this is a Finding.
Fixes:
Develop, document and implement procedures for authorizing creation, changes and deletions of
user accounts.
Monitor user accounts to verify that they remain authorized.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0003815
DG0071
11
Active
DBMS password change variance
New passwords should be required to differ from old passwords by more than four characters.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
DG0071-ORACLE11
Category II
Changing passwords frequently can thwart password-guessing attempts or re-establish protection

of a compromised DBMS account. Minor changes to passwords may not accomplish this as
password guessing may be able to continue to build on previous guesses or the new password
may be easily guessed using the old password.
New passwords are not required to differ from old passwords by more than four characters.
Yes
Review the profile and limit as generated. Confirm the limit identifies a valid password verify
function containing the required code is documented, authorized and accept as Documentable in
VMS.
References:
8/19/2010
VL05
Page 18 of 130

IAIA-1, IAIA-2
Checks:
If no DBMS accounts authenticate using passwords, this check is Not a Finding.
Confirm that database profiles specify a password verify function.
From SQL*Plus:
select profile, limit from dba_profiles
where resource_name='PASSWORD_VERIFY_FUNCTION'
and limit not in ('NULL', 'DEFAULT')
order by profile;
If no rows are listed, this is a Finding.
Review the code for the password verify function or have the DBA demonstrate a password
change to ensure that the function requires new passwords to differ from old passwords by more
than 4 characters.
If reviewing code, logic similar to the following should be discovered:
-- Check if the password differs from the previous password
-- by more than 4 characters
<<endsearch>>
if old_password is not null then
differ:=length(old_password) - length(password);
if abs(differ) < 4 then
if length(password) < length(old_password) then
m:=length(password);
else
m:=length(old_password);
end if;
differ:=abs(differ);
for i in 1..m loop
if substr(password,i,1) != substr(old_password,i,1) then
differ:=differ + 1;
end if;
end loop;
if differ < 4 then
raise_application_error(-20004, 'Password should differ by more than 4 characters');
end if;
end if;
end if;
If any password_verify_function routines do not check for a difference of more than 4 characters,
this is a Finding.
Fixes:
Define and apply a password_verify_function for all profiles where passwords are used to
authenticate accounts.
See Fix information for DG0079 to create a password_verify_function that meets STIG
requirements.
8/19/2010
VL05
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
Page 19 of 130
DG0073
8
Active
DBMS failed login account lock
Database accounts should not specify account lock times less than the site-approved minimum.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0073-ORACLE11
Category II
The FAILED_LOGIN_ATTEMPTS value limits the number of failed login attempts allowed before
an account is locked. Setting this value limits the ability of unauthorized users to guess
passwords and alerts the DBA when password guessing has occurred (accounts display as
locked). For non-interactive accounts, the number of failed logins should be set to an IAOapproved value.
Database accounts specify account lock times less than the site-approved minimum.
Yes
Review the profile and limit as generated. Confirm the limit for any non-DEFAULT profiles
returned are documented, authorized and accept as Documentable in VMS.
ECLO-1, ECLO-2
From SQL*Plus:
select profile||': '||limit from dba_profiles,
(select limit as def_login_attempts from dba_profiles
where profile = 'DEFAULT'
and resource_name = 'FAILED_LOGIN_ATTEMPTS')
where resource_name = 'FAILED_LOGIN_ATTEMPTS'
and replace(limit, 'DEFAULT', def_login_attempts) IN
('UNLIMITED', NULL)
or resource_name = 'FAILED_LOGIN_ATTEMPTS'
and to_number(decode(limit, 'UNLIMITED', 10, 'DEFAULT', 10, limit)) > 3;
If the DEFAULT profile is returned with a limit not less than or equal to 3, this is a Finding.
8/19/2010
VL05
Page 20 of 130
If any non-DEFAULT profiles are returned with limits not documented and approved by the IAO,
this is a Finding.
NOTE: If the limit 'DEFAULT' is returned for any non-DEFAULT profiles, the profile limit is set to
the corresponding value in the DEFAULT profile. If the DEFAULT profile is a Finding, so is the
profile that references it.
Fixes:
Modify profiles to meet the failed login attempt requirement limit.
From SQL*Plus:
alter profile default limit
failed_login_attempts 3;
alter profile [profile name] limit
failed_login_attempts [IAO-approved value];
Replace [profile name] with any existing, non-default profile names.
Document in the System Security Plan all profiles and settings.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015130
DG0074
8
Active
DBMS inactive accounts
Unapproved inactive or expired database accounts should not be found on the database.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
DG0074-ORACLE11
Category II
Unused or expired DBMS accounts provide a means for undetected, unauthorized access to the
database.
Unapproved inactive or expired database accounts have been found on the database.
8/19/2010
VL05
Page 21 of 130
Documentable: No
Documentable
Explanation:
References:
IAAC-1
Checks:
Review procedures and implementation for monitoring the DBMS for account expiration and
account inactivity.
Verify implemented procedures are in place to address expired/locked accounts not required for
system/application operation are authorized to remain and are documented.
Verify implemented procedures are in place to address accounts that are unlocked and have been
inactive in excess of 30 days are authorized to remain unlocked.
Verify implemented procedures are in place to address unauthorized, inactive accounts after 30
days are expired and locked.
Verify implemented procedures are in place to address expired/locked accounts that are not
authorized to remain are dropped/removed/deleted.
A finding for this check would be based on insufficient documentation and implemented
procedures for monitoring DBMS accounts.
Fixes:
Develop, document and implement procedures to monitor database accounts for inactivity and
account expiration.
Investigate and re-authorize or delete [if appropriate] any accounts that are expired or have been
inactive for more than 30 days.
Where appropriate, protect authorized expired or inactive accounts by disabling them or applying
some other similar protection.
NOTE: Password and account requirements have changed for DoD since this STIG requirement
was published.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0003818
DG0075
11
Active
DBMS links to external databases
Unauthorized database links should not be defined and active.
Comments:
Not a Finding
Not Applicable
Not Reviewed
8/19/2010
VL05
Condition:
Page 22 of 130
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0075-ORACLE11
Category II
DBMS links provide a communication and data transfer path definition between two databases that
may be used by malicious users to discover and obtain unauthorized access to remote systems.
Database links between production and development DBMSs provide a means for developers to
access production data not authorized for their access or to introduce untested or unauthorized
applications to the production database. Only protected, controlled, and authorized downloads of
any production data to use for development should be allowed. Only applications that have
completed the configuration management process should be introduced by the application object
owner account to the production system.
Unauthorized database links are defined and active.
Yes
Review the DB link name and host as generated. Confirm the link is documented, authorized and
accept as Documentable in VMS.
Department of Defense (DOD) Instruction 8500.2, Information Assurance (IA) Implementation App.
A, Enclosure A, Para.5.b (8)
DCFA-1
Database Security Technical Implementation Guide 3.1.4.1
From SQL*Plus:
select db_link||': '||host from dba_db_links;
If no links are returned, this check is Not a Finding.
Review documentation for definitions of authorized database links to external interfaces.
The documentation should include:
- Any remote access to the database
- The purpose or function of the remote connection
- Any access to data or procedures stored externally to the local DBMS
- Any network ports or protocols used by remote connections, whether the remote connection is to
a production, test, or development system
- Any security accounts used by DBMS to access remote resources or objects
If any unauthorized database links are defined or the definitions do not match the documentation,
this is a Finding.
NOTE: Findings for production-development links under this check are assigned to the production
database only.
If any database links are defined between the production database and any test or development
databases, this is a Finding.
8/19/2010
VL05
Page 23 of 130
If remote interface documentation does not exist or is incomplete, this is a Finding.

Fixes:
Document all remote or external interfaces used by the DBMS to connect to or allow connections
from remote or external sources.
Include with the documentation as appropriate, any network ports or protocols, security accounts,
and the sensitivity of any data exchanged.
Do not define or configure database links between production databases and test or development
databases.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
V0003819
DG0076
11
Active
Sensitive data import to development DBMS
Sensitive information from production database exports should be modified after import to a
development database.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
DG0076-ORACLE11
Category II
Data export from production databases may include sensitive data. Application developers do not
have a need to know to sensitive data. Any access they may have to production data would be
considered unauthorized access and subject the sensitive data to unlawful or unauthorized
disclosure. See DODD 8500.1 for a definition of Sensitive Information.
Sensitive information from production database exports remains unmodified after import to a
development database.
No
8/19/2010
VL05
Page 24 of 130

ECAN-1
Checks:
If the database being reviewed is not a production database, this check is Not a Finding.
Review policy, procedures and restrictions for data imports of production data containing sensitive
information into development databases.
If data imports of production data are allowed, review procedures for protecting any sensitive data
included in production exports.
If sensitive data is included in the exports and no procedures are in place to remove or modify the
data to render it not sensitive prior to import into a development database or policy and
procedures are not in place to ensure authorization of development personnel to access sensitive
information contained in production data, this is a Finding.
Fixes:
Develop, document and implement policy, procedures and restrictions for production data import.
Require any users assigned privileges that allow the export of production data from the database
to acknowledge understanding of import policies, procedures and restrictions.
Restrict permissions of development personnel requiring use or access to production data
imported into development databases containing sensitive information to authorized users.
Implement policy and procedures to modify or remove sensitive information in production exports
prior to import into development databases.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0003820
DG0077
11
Active
Production data protection on a shared system
Production databases should be protected from unauthorized access by developers on shared
production/development host systems.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
DG0077-ORACLE11
Category II
Severity
8/19/2010
VL05
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Page 25 of 130
Developers granted elevated database, operating system privileges on systems that support both
development, and production databases can affect the operation and/or security of the production
database system. Operating system and database privileges assigned to developers on shared
development and production systems should be restricted.
Production databases are not protected from unauthorized access by developers on shared
production/development host systems.
Yes
Review the accounts and privileges as generated. Confirm the account(s) and privileges are
ECLP-1
Review the list of instances and databases installed on the host system with the DBA.
Ask which databases are production databases and which are for development.
For UNIX systems, use the ps -ef|grep pmon command to see the list of databases; For Windows
systems, review the list of services beginning with the name OracleService to see the list of
databases.
Ask which databases are production databases and which are for development.
If only development or only production databases exist on this host, this check is Not a Finding.
Otherwise, ask the DBA to confirm that policy and procedures are in place for the IAO to review
database and operating system privileges on the system to ensure developer accounts do not
have access to production DBMS systems.
If none are in place, this is a Finding.
Ask the DBA/SA if developer host accounts have been granted privileges to production database
directories, files or resources.
If they have been, this is a Finding.
select grantee||': '||privilege from dba_sys_privs
where (privilege like 'CREATE%' or privilege like 'ALTER%'
or privilege like 'DROP%')
and privilege<>'CREATE SESSION'
and grantee not in
'AURORA$ORB$UNAUTHENTICATED','CTXSYS','DBSNMP','DIP',
'DVF','DVSYS','EXFSYS','LBACSYS','MDDATA','MDSYS','MGMT_VIEW',
'ODM','ODM_MTR','OLAPSYS','ORDPLUGINS','ORDSYS',
'OSE$HTTP$ADMIN','OUTLN','PERFSTAT','PUBLIC','REPADMIN',
'RMAN','SI_INFORMTN_SCHEMA','SYS','SYSMAN','SYSTEM',
'TRACESVR','TSMSYSWK_TEST','WKPROXY','WKSYS','WKUSER',
'WMSYS','XDB')
order by grantee;
If any accounts are listed that are not on the list of IAO approved production DBAs, this is a
Finding.
NOTE: Though shared production/non-production DBMS installations was allowed under previous
8/19/2010
VL05
Page 26 of 130
database STIG guidance, doing so may place it in violation of OS, Application, Network or
Enclave STIG guidance. Ensure that any shared production/non-production DBMS installations
meets STIG guidance requirements at all levels or mitigate any conflicts in STIG guidance with
your DAA.
Fixes:
Develop, document and implement procedures to review and maintain privileges granted to
developers on shared production and development host systems and databases.
Recommend establishing a dedicated DBMS host for production DBMS installations (See Checks
DG0109 and DG0110).
A dedicated host system in this case refers to an instance of the operating system at a minimum.
The operating system may reside on a virtual host machine where supported by the DBMS vendor.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015613
DG0078
5
Active
DBMS individual accounts
Each database user, application or process should have an individually assigned account.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
DG0078-ORACLE11
Category II
Use of accounts shared by multiple users, applications, or processes limit the accountability for
actions taken in or on the data or database. Individual accounts provide an opportunity to limit
database authorizations to those required for the job function assigned to each individual account.
Each database user, application or process does not have an individually assigned account.
No
8/19/2010
VL05
Page 27 of 130

Department of Defense (DOD) Instruction 8500.2, Information Assurance (IA) Implementation IAIA1, IAIA-2
Checks:
Review DBMS account names against the list of authorized DBMS accounts in the System
Security Plan.
If any accounts indicate use by mulitiple persons that are not mapped to a specific person, this is
a Finding.
If any applications or processes share an account that could be assigned an individual account or
are not specified as requiring a shared account, this is a Finding.
Note: Privileged installation accounts may be required to be accessed by DBA or other
administrators for system maintenance. In these cases, each use of the account must be logged
in some manner to assign accountability for any actions taken during the use of the account.
Fixes:
Create individual accounts for each user, application, or other process that requires a database
connection.
Document any accounts that are shared where separation is not supported by the application or
for maintenance support.
Design, develop and implement a method to log use of any account to which more than one
person has access.
Restrict interactive access to shared accounts to the fewest persons possible.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015152
DG0079
6
Active
DBMS password complexity
DBMS login accounts require passwords to meet complexity requirements.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
DG0079-ORACLE11
Category II
8/19/2010
VL05
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Page 28 of 130
The PASSWORD_VERIFY_FUNCTION value specifies a PL/SQL function to be used for

password verification when users assigned this profile log in to a database. This function can be
used to validate password strength by requiring passwords to pass a strength test written in
PL/SQL. The function must be locally available for execution on the database to which this profile
applies. Oracle provides a default script (utlpwdmg.sql), as a template to develop your own
function. The password verification function must be owned by SYS. The default setting for this
profile parameter is NULL, meaning no password verification is performed.
DBMS login account passwords do not meet complexity requirements.
No
IAIA-1, IAIA-2
JTF-GNO Communications Tasking Order (CTO) 07-015, Public Key Infrastructure (PKI)
Implementation, Phase 2
From SQL*Plus:
select profile, limit
from dba_profiles,
(select limit as def_pwd_verify_func
from dba_profiles
and profile='DEFAULT')
and replace(limit, 'DEFAULT', def_pwd_verify_func) in
('UNLIMITED', NULL);
If any records are returned, this is a Finding.
Fixes:
Create or use a password verify function that enforces password complexity.
See a sample below that meets DoD requirements.
Modify profiles to specify the password verify function created.
From SQL*Plus:
Rem This script was modified from the Oracle utlpwdmg.sql default script.
Rem
-- This script sets the default password resource parameters.
-- This script needs to be run to enable the password features.
-- However, the default resource parameters can be changed based on the need.
-- A default password complexity function is also provided.
-- This function makes the minimum complexity checks like the minimum
-- length of the password, password not same as the username, etc. The user may
-- enhance this function according to the need.
-- This function must be created in SYS schema:
-- connect sys/<password> as sysdba before running the script
CREATE OR REPLACE FUNCTION verify_password_dod
(username varchar2,
8/19/2010
VL05
Page 29 of 130
password varchar2,
old_password varchar2)
RETURN boolean IS
n boolean;
m integer;
differ integer;
isdigit boolean;
numdigit integer;
ispunct boolean;
numpunct integer;
islowchar boolean;
numlowchar integer;
isupchar boolean;
numupchar integer;
digitarray varchar2(10);
punctarray varchar2(25);
lowchararray varchar2(26);
upchararray varchar2(26);
pw_change_time date;
BEGIN
digitarray:='0123456789';
lowchararray:='abcdefghijklmnopqrstuvwxyz';
upchararray:='ABCDEFGHIJKLMNOPQRSTUVWXYZ';
punctarray:='@!"#$%&()``*+,-/:;<=>?_';
-- Check if the password is same as the username
if nls_lower(password)=nls_lower(username) then
raise_application_error(-20001, 'Password same as or similar to user');
end if;
-- Check for the minimum length of the password
if length(password) < 15 then
raise_application_error(-20002, 'Password length less than 15');
end if;
-- Check if the password is too simple. A dictionary of words may be maintained
-- and a check may be made so as not to allow the words that are too simple for
-- the password.
if nls_lower(password) in
('welcome','database','account','user','password','oracle','computer','abcdefgh',
'12345') then
raise_application_error(-20002, 'Password too simple');
end if;
-- Check if the password contains at least two each of the following:
-- uppercase characters, lowercase characters, digits and special characters.
-- 1. Check for the digits
isdigit:=FALSE;
numdigit:=0;
for i in 1..10 loop
for j in 1..m loop
if substr(password,j,1)=substr(digitarray,i,1) then
numdigit:=numdigit + 1;
end if;
if numdigit > 1 then
isdigit:=TRUE;
goto findlowchar;
end if;
end loop;
end loop;
if isdigit=FALSE then
8/19/2010
VL05
Page 30 of 130
raise_application_error(-20003, 'Password should contain at least two digits');

end if;
-- 2. Check for the lowercase characters
<<findlowchar>>
islowchar:=FALSE;
numlowchar:=0;
for i in 1..length(lowchararray) loop
for j in 1..m loop
if substr(password,j,1)=substr(lowchararray,i,1) then
numlowchar:=numlowchar + 1;
end if;
if numlowchar > 1 then
islowchar:=TRUE;
goto findupchar;
end if;
end loop;
end loop;
if islowchar=FALSE then
raise_application_error(-20003, 'Password should contain at least two lowercase characters');
end if;
-- 3. Check for the UPPERCASE characters
<<findupchar>>
isupchar:=FALSE;
numupchar:=0;
for i in 1..length(upchararray) loop
for j in 1..m loop
if substr(password,j,1)=substr(upchararray,i,1) then
numupchar:=numupchar + 1;
end if;
if numupchar > 1 then
isupchar:=TRUE;
goto findpunct;
end if;
end loop;
end loop;
if isupchar=FALSE then
raise_application_error(-20003, 'Password should contain at least two uppercase characters');
end if;
-- 4. Check for the punctuation
<<findpunct>>
ispunct:=FALSE;
numpunct:=0;
for i in 1..length(punctarray) loop
for j in 1..m loop
if substr(password,j,1)=substr(punctarray,i,1) then
numpunct:=numpunct + 1;
end if;
if numpunct > 1 then
ispunct:=TRUE;
goto endsearch;
end if;
end loop;
8/19/2010
VL05
Page 31 of 130
end loop;
if ispunct=FALSE then
raise_application_error(-20003, 'Password should contain at least two punctuation characters');
end if;
-- Check if the password differs from the previous password
-- by more than 4 characters
<<endsearch>>
if old_password is not null then
differ:=length(old_password) - length(password);
if abs(differ) < 4 then
if length(password) < length(old_password) then
else
m:=length(old_password);
end if;
differ:=abs(differ);
for i in 1..m loop
if substr(password,i,1) != substr(old_password,i,1) then
differ:=differ + 1;
end if;
end loop;
if differ < 4 then
raise_application_error(-20004, 'Password should differ by more than 4 characters');
end if;
end if;
end if;
-- Everything is fine. return TRUE
RETURN(TRUE);
EXCEPTION
WHEN OTHERS THEN
raise_application_error(-20000,'verify_password_dod: Unexpected error: '||SQLERRM,TRUE);
END;
/
password_verify_function verify_password_dod;
NOTE: Password and account requirements have changed for DoD since the STIG requirement
listed in the table for this check was published.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0003821
DG0080
10
Active
DBMS application user privilege assignment review
Application user privilege assignment should be reviewed monthly or more frequently to ensure
compliance with least privilege and documented policy.
Comments:
Not a Finding
8/19/2010
VL05
Page 32 of 130
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DG0080-ORACLE11
Category II
Users granted privileges not required to perform their assigned functions are able to make
unauthorized modifications to the production data or database. Monthly or more frequent periodic
review of privilege assignments assures that organizational and/or functional changes are reflected
appropriately.
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Application user privilege assignment is not reviewed monthly or more frequently to ensure
compliance with least privilege and documented policy.
No
ECLP-1
Review policy, procedures and implementation evidence to determine if periodic reviews of user
privileges by the IAO are being performed.
Evidence may consist of email or other correspondence that acknowledges receipt of periodic
reports and notification of review between the DBA and IAO or other auditors as assigned.
If policy and procedures are incomplete or no evidence of implementation exists, this is a Finding.
Fixes:
Develop, document and implement policy and procedures for periodic review of database user
accounts and privilege assignments.
Include methods to provide evidence of review in the procedures to verify reviews occur in
accordance with the procedures.
Vulnerability Key:
STIG ID:
Release Number:
Status:
V0015615
DG0085
4
Active
8/19/2010
VL05
Short Name:
Long Name:
Open
Page 33 of 130
Minimum DBA privilege assignment

The DBA role should not be assigned excessive or unauthorized privileges.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0085-ORACLE11
Category II
Oracle SYSDBA privileges include privileges to administer the database outside of database
controls (when the database is shut down or open in restricted mode) in addition to all privileges
controlled under database operation. Assignment of SYSDBA privileges in the Oracle password
file to unauthorized persons can compromise all DBMS activities.
The DBA role is assigned excessive or unauthorized privileges.
Yes
Review the accounts as generated. Confirm the account(s) are documented, authorized and
accept as Documentable in VMS.
ECLP-1
From SQL*Plus:
select username from v$pwfile_users
where username not in
(select grantee from dba_role_privs where granted_role='DBA')
and username<>'INTERNAL'
and (sysdba = 'TRUE' or sysoper='TRUE');
If any accounts are listed and are not authorized by the IAO in the System Security Plan, this is a
Finding.
Fixes:
If a REMOTE_LOGIN_PASSWORDFILE is in use (='EXCLUSIVE'), list database accounts
assigned SYSDBA and SYSOPER database privileges and review for appropriate authorization.
Document authorized SYSDBA and SYSOPER users in the System Security Plan.
8/19/2010
VL05
Page 34 of 130
From SQL*Plus:
select * from v$pwfile_users;
To revoke SYSDBA or SYSOPER from accounts:
From SQL*Plus:
revoke sysdba from [username];
revoke sysoper from [username];
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
V0015616
DG0087
6
Active
DBMS sensitive data labeling
Sensitive data should be labeled.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0087-ORACLE11
Category III
The sensitivity marking or labeling of data items promotes the correct handling and protection of
the data. Without such notification, the user may unwittingly disclose sensitive data to
unauthorized users.
Sensitive data is not labeled.
No
ECML-1
If database does not contain sensitive data, this check is Not a Finding.
8/19/2010
VL05
Page 35 of 130
If Oracle Label Security is not installed and database contains sensitive data, this is a Finding.
From SQL*Plus:
select * from DBA_SA_USERS;
Compare results to the requirements for labeling as specified in the System Security Plan.
If label security is not configured as specified in the System Security Plan, this is a Finding.
Fixes:
Develop, document and implement label security requirements.
Install and configure label security in accordance with the System Security Plan.
Monitor and audit changes to the label security configuration.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015114
DG0089
8
Active
Developer DBMS privileges on production databases
Developers should not be assigned excessive privileges on production databases.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DG0089-ORACLE11
Category III
Developers play a unique role and represent a specific type of threat to the security of the DBMS.
Where restricted resources prevent the required separation of production and development DBMS
installations, developers granted elevated privileges to create and manage new database objects
must also be prevented from actions that can threaten the production operation.
Default
Finding
Developers are assigned excessive privileges on production databases.
Details:
Documentable: No
Documentable
Explanation:
8/19/2010
VL05
Page 36 of 130

References:
ECPC-1, ECPC-2
Checks:
If this database is not a production database, this check is Not a Finding.

Review the privileges assigned to developer accounts.
Identify login name of developer DBMS accounts from the System Security Plan and/or DBA.
For each developer account, display the roles assigned to the account.
From SQL*Plus:
select granted_role from dba_role_privs where grantee=[developer account name];
If privileges assigned to developer accounts are not restricted to development objects and
configurations, or authorizations to allow developer account access to production objects and
configurations does not exist in the System Security Plan, this is a Finding.
Fixes:
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
Revoke permissions and privileges that allow changes to the production system or production
objects from developer accounts or authorize permissions and privileges for developer accounts
in the System Security Plan.
V0003823
DG0091
11
Active
DBMS source code encoding or encryption
Custom and GOTS application source code stored in the database should be protected with
encryption or encoding.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
DG0091-ORACLE11
Category III
Severity
8/19/2010
VL05
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Page 37 of 130
Source code may include information on data relationships, locations of sensitive data that are
otherwise obscured, or other processing information that could aid a malicious user. Encoding or
encryption of the custom source code objects within the database helps protect against this type of
disclosure.
Custom and GOTS application source code stored in the database has not been protected with
encryption or encoding.
Yes
Review the accounts and objects as generated. Confirm the objects are documented, authorized
and accept as Documentable in VMS.
DCSL-1
If this is not a production database, this check is Not a Finding.
select owner||'.'||name from dba_source
where line=1 and owner not in
('SYS', 'CTXSYS', 'MDSYS', 'ODM', 'OE', 'OLAPSYS', 'ORDPLUGINS',
'ORDSYS', 'OUTLN', 'PM', 'QS_ADM', 'RMAN', 'SYSTEM', 'WKSYS',
'WMSYS', 'XDB')
and owner not like 'OEM%'
and text not like '%wrapped%'
and type in ('PROCEDURE', 'FUNCTION', 'PACKAGE BODY');
Review the list of results with the DBA. If any results are custom or GOTS application code, this is
a Finding. If all returned results are default DBMS or COTS application code, this is not a Finding.
Fixes:
Use the Oracle WRAP utility to encode application source code stored in application database
objects (stored procedures, functions, package bodies).
The following may be used as an example process:
1) export the application object source and store in an external file.
From SQL*Plus:
set show off
set heading off
set verify off
set echo off
set term off
set pagesize 0
set feedback off
set serveroutput on size 1000000
set wrap on
set trimspool on
set linesize 512
spool [output file name = proc.sql]
select text from dba_source
where object_name='[object name]';
spool off
2) From system command line, invoke the wrap utility.
8/19/2010
VL05
Page 38 of 130
wrap iname=proc.sql oname=proc.plb

This will result in the file name proc.plb
3) re-create the object with the encoded source code.
From SQL*Plus:
@proc.plb
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015617
DG0098
4
Active
DBMS access to external local objects
Access to external objects should be disabled if not required and authorized.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
DG0098-ORACLE11
Category II
The UTL_FILE package allows host file access from within the database using the permissions
and privileges assigned to the Oracle database process or service. This package should be used
with caution. All files accessible to using this package is equally accessible to any database user
with execute permissions to the UTL_FILE package. When UTL_FILE_DIR is set to *, all
directories accessible to the Oracle database process, typically the Oracle installation account, are
accessible via the UTL_FILE package. This setting effectively turns off directory access checking,
and makes any directory accessible to the UTL_FILE functions. The UTL_FILE_DIR list should
specify only authorized and protected directories and should include only fully specified path
names.
Access to external objects has not been disabled and is not required or authorized.
No
8/19/2010
VL05
Page 39 of 130

DCFA-1
Checks:
From SQL*Plus:
select value from v$parameter where name='utl_file_dir';
If the returned value contains '*', this is a Finding.
Fixes:
Where its use is authorized, restrict access by a database session to external host files.
From SQL*Plus:
alter system set utl_file_dir=[authorized directory] scope=spfile;
Replace [authorized directory] with the directory path where file access and storage is authorized.
Review Oracle MetaLink Note 39037.1 if you need to define multiple authorized directories.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015619
DG0100
7
Active
DBMS replication account privileges
Replication accounts should not be granted DBA privileges.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DG0100-ORACLE11
Category II
Replication accounts may be used to access databases defined for the replication architecture.
An exploit of a replication on one database could lead to the compromise of any database
participating in the replication that uses the same account name and credentials. If the replication
account is compromised and it has DBA privileges, the database is at additional risk to
unauthorized or malicious action.
8/19/2010
VL05
Page 40 of 130
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Replication accounts are granted DBA privileges.

No
DCFA-1
If a review of the System Security Plan confirms the use of replication is not required, not
permitted and the database is not configured for replication, this check is Not a Finding.
If any replication accounts are assigned DBA roles or roles with DBA privileges, this is a Finding.
Fixes:
Restrict privileges assigned to replication accounts to the fewest possible privileges.
Remove DBA roles from replication accounts.
Create and use custom replication accounts assigned least privileges for supporting replication
operations.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015128
DG0105
7
Active
DBMS application user role privilege assignment
DBMS application user roles should not be assigned unauthorized privileges.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
DG0105-ORACLE11
Category II
8/19/2010
VL05
Page 41 of 130
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Unauthorized access to the data can lead to loss of confidentiality and integrity of the data.
DBMS application user roles are assigned unauthorized privileges.
No
DCFA-1
Compare privileges assigned to database application user roles to those defined in the System
Security Plan.
If the assigned privileges do not match the authorized list of privileges, this is a Finding.
Fixes:
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
Use the grant and revoke commands to assign the authorized privileges as listed in the System
Security Plan to custom database application or application user roles.
V0015623
DG0112
7
Active
DBMS system data file protection
DBMS system data files should be stored in dedicated disk directories.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
DG0112-ORACLE11
Category II
DBMS system data files have different access control requirements than application data and log
8/19/2010
VL05
Page 42 of 130
Discussion:
files. Granting access to system data files beyond those required for system operations could lead
to a compromise of the DBMS integrity or disclosure of sensitive data.
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DBMS system data files are not stored in dedicated disk directories.
No
DCPA-1
From SQL*Plus:
select file_name from dba_data_files
where tablespace_name='SYSTEM';
NOTE: Data files for a given database instance may include data files (*.dbf), REDO log files
(redo*.log) and CONTROL files (*.ctl).
Review the files in the directory shown above.
Allowable files are instance database files (*.dbf), REDO log files (redo*.log) and CONTROL files
(*.ctl).
If any files other than these exist in the directory, this is a Finding.
A good best practice (not consistently endorsed by the Oracle community) is on database
creation, using separate subdirectories for data, redo and control files [under the instance name
directory] instead of using a single directory to contain all Oracle data, redo and control instance
files.
Fixes:
Create a dedicated directory or dedicated subdirectories to store database instance files.
Reconfigure the Oracle instance to point to the files in the new locations.
Where feasible, locate database instance files on a dedicated disk partition and/or RAID device to
provide additional protection.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015624
DG0113
4
Active
DBMS dedicated data files
DBMS data files should be dedicated to support individual applications.
Comments:
Not a Finding
Not Applicable
Not Reviewed
8/19/2010
VL05
Page 43 of 130
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DG0113-ORACLE11
Category II
DBMS data files may contain database objects supporting different applications. Shared
resources and access to storage locations may lead to one application being vulnerable to the
exploit or resource needs of the other. Dedicating data files to each application provides a
means to separate by privilege assignment and resource quotas and protect one application
from security issues of another.
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DBMS data files are not dedicated to support individual applications.

No
DCPA-1
Review application database tables and their database file assignments.
If application database tables from unrelated applications are stored in the same database data
files, this is a Finding.
Fixes:
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
Relocate application database tables to distinct database data files where supported by the
DBMS.
V0015626
DG0116
4
Active
DBMS privileged role assignments
Database privileged role assignments should be restricted to IAO-authorized DBMS accounts.
Comments:
Not a Finding
Not Applicable
Not Reviewed
8/19/2010
VL05
Condition:
Page 44 of 130
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0116-ORACLE11
Category II
Roles assigned privileges to perform DDL and/or system configuration actions in the database can
lead to compromise of any data in the database as well as operation of the DBMS itself. Restrict
assignment of privileged roles to authorized personnel and database accounts to help prevent
unauthorized activity.
Database privileged role assignments are not restricted to IAO-authorized DBMS accounts.
Yes
Review the accounts and role assignments as generated. Confirm the account(s) and role
assignments are documented, authorized and accept as Documentable in VMS.
ECLP-1
From SQL*Plus (NOTE: The owner list below is a short list of all possible default Oracle accounts
and roles):
select grantee||': '||granted_role from dba_role_privs
where grantee not in
'AURORA$ORB$UNAUTHENTICATED','CTXSYS','DBSNMP','DIP',
'DMSYS','DVF','DVSYS','EXFSYS','LBACSYS','MDDATA','MDSYS',
'MGMT_VIEW','ODM','ODM_MTR','OLAPSYS','ORDPLUGINS','ORDSYS',
'OSE$HTTP$ADMIN','OUTLN','PERFSTAT','REPADMIN','RMAN',
'SI_INFORMTN_SCHEMA','SYS','SYSMAN','SYSTEM','TRACESVR',
'TSMSYS','WK_TEST','WKPROXY','WKSYS','WKUSER','WMSYS','XDB')
and grantee not in
('DBA', 'OLAP_USER', 'IP', 'ORASSO_PUBLIC',
'PORTAL_PUBLIC', 'DATAPUMP_EXP_FULL_DATABASE',
'DATAPUMP_IMP_FULL_DATABASE', 'EXP_FULL_DATABASE',
'IMP_FULL_DATABASE', 'OLAP_DBA', 'EXECUTE_CATALOG_ROLE',
'SELECT_CATALOG_ROLE', 'JAVASYSPRIV')
and grantee not in
(select grantee from dba_role_privs where granted_role = 'DBA')
and grantee not in (select distinct owner from dba_objects)
and granted_role in
('AQ_ADMINISTRATOR_ROLE','AQ_USER_ROLE',
'CTXAPP',
'DELETE_CATALOG_ROLE','EJBCLIENT','EXECUTE_CATALOG_ROLE',
'EXP_FULL_DATABASE','GATHER_SYSTEM_STATISTICS',
'GLOBAL_AQ_USER_ROLE','HS_ADMIN_ROLE',
8/19/2010
VL05
Page 45 of 130
'IMP_FULL_DATABASE','JAVADEBUGPRIV','JAVAIDPRIV',
'JAVASYSPRIV','JAVAUSERPRIV','JAVA_ADMIN','JAVA_DEPLOY',
'LOGSTDBY_ADMINISTRATOR','OEM_MONITOR','OLAP_DBA',
'RECOVERY_CATALOG_OWNER',
'SALES_HISTORY_ROLE','SELECT_CATALOG_ROLE','WKUSER',
'WM_ADMIN_ROLE','XDBADMIN')
and granted_role not in ('CONNECT', 'RESOURCE', 'AUTHENTICATEDUSER')
order by grantee;
If any records are returned, confirm the grantee and role are documented in the System Security
Plan and authorized by the IAO.
If not documented and approved, this is a Finding.
Fixes:
Create custom roles for each discrete application user / administrator function required for your
database and assign the minimum privileges necessary to perform the function.
Assign custom roles to accounts.
Revoke assignment of predefined roles from accounts where not documented in the System
Security Plan and authorized by the IAO.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015627
DG0117
8
Active
DBMS administrative privilege assignment
Administrative privileges should be assigned to database accounts via database roles.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DG0117-ORACLE11
Category II
Privileges granted outside the role of the administrative user job function are more likely to go
unmanaged or without oversight for authorization. Maintenance of privileges using roles defined for
discrete job functions offers improved oversight of administrative user privilege assignments and
helps to protect against unauthorized privilege assignment.
Default
8/19/2010
VL05
Page 46 of 130
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Administrative privileges are not assigned to database accounts via database roles.
No

ECPA-1
select grantee||': '||privilege
from dba_sys_privs
('SYS', 'SYSTEM', 'SYSMAN', 'CTXSYS', 'MDSYS', 'WKSYS')
and grantee not in
(select distinct granted_role from dba_role_privs)
and privilege <> 'UNLIMITED TABLESPACE'
order by grantee;
NOTE: Disregard any default database component account privilege assignments that may be
returned.
If administrative privileges have been assigned directly to an account, this is a Finding.
Fixes:
Revoke assigned administrative privileges from database accounts and assign to accounts via
roles.
Document roles and assignments in the System Security Plan.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015628
DG0119
4
Active
DBMS application user role privileges
DBMS application users should not be granted administrative privileges to the DBMS.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
8/19/2010
VL05
Page 47 of 130
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DG0119-ORACLE11
Category II
Excessive privileges can lead to unauthorized actions on data and database objects. Assigning
only the privileges required to perform the job function authorized for the user helps protect against
exploits against application vulnerabilities such as SQL injection attacks. The recommended
method is to grant access only to stored procedures that perform only static actions on the data
authorized for the user. Where this is not feasible, consider using data views or other methods to
restrict users to only the data suitable for their job function.
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DBMS application users are granted administrative privileges to the DBMS.

No
ECLP-1
select grantee, owner, table_name, privilege from dba_tab_privs
where privilege in ('ALTER', 'REFERENCES', 'INDEX')
and grantee not in ('DBA', 'SYS', 'SYSTEM', 'LBACSYS', 'XDBADMIN')
and table_name not in
('SDO_IDX_TAB_SEQUENCE', 'XDB$ACL', 'XDB_ADMIN')
and grantee not in
and grantee not in (select distinct owner from dba_objects);
Fixes:
Revoke ALTER, REFERENCES, and INDEX privileges from application user roles.
From SQL*Plus:
revoke [privilege] from [application user role];
Replace [privilege] with the identified ALTER, REFERENCES or INDEX privilege and [application
user role] with the identified application role.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
V0015629
DG0121
4
Active
DBMS application user privilege assignment
Application users privileges should be restricted to assignment using application user roles.
8/19/2010
VL05
Open
Page 48 of 130
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
DG0121-ORACLE11
Category II
Granting permissions to accounts is error prone and repetitive. Using roles allows for group
management of privileges assigned by function and reduces the likelihood of wrongfully assigned
privileges. Assign permissions to roles and then grant the roles to accounts.
Application users privileges have not been restricted to assignment using application user roles.
Yes
Review the accounts, privileges, object owners and objects as generated. Confirm the account(s)
and privilege assignments to the objects are documented, authorized and accept as Documentable
in VMS.
References:
ECLP-1
Checks:
select grantee||': '||privilege||': '||owner||'.'||table_name
from dba_tab_privs where grantee not in
(select role from dba_roles)
and grantee not in
('APEX_PUBLIC_USER', 'AURORA$JIS$UTILITY$', 'CTXSYS',
'DBSNMP', 'EXFSYS', 'FLOWS_030000', 'FLOWS_FILES',
'LBACSYS', 'MDSYS', 'MGMT_VIEW', 'ODM', 'OLAPSYS',
'ORACLE_OCM', 'ORDPLUGINS', 'ORDSYS',
'OSE$HTTP$ADMIN', 'OUTLN', 'OWBSYS', 'PERFSTAT',
'PUBLIC', 'REPADMIN', 'SYS', 'SYSMAN', 'SYSTEM',
'WKSYS', 'WMSYS', 'XDB')
and table_name<>'DBMS_REPCAT_INTERNAL_PACKAGE'
and table_name not like '%RP'
and grantee not in
(select grantee from dba_tab_privs
where table_name in ('DBMS_DEFER', 'DEFLOB'));
8/19/2010
VL05
Page 49 of 130
NOTE: This check may report false positives where other ORACLE products have been installed.
Accounts installed with other Oracle products are exempt from this requirement.
Fixes:
Revoke privileges assigned directly to database accounts and assign them to roles based on job
functions.
Assign users who are assigned responsibility for the job function to the defined role.
From SQL*Plus:
revoke [privilege] on [object name] from [user name];
grant [privilege] on [object name] to [role name];
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015630
DG0122
4
Active
Sensitive data access
Access to sensitive data should be restricted to authorized users identified by the Information
Owner.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DG0122-ORACLE11
Category II
The Oracle parameter file contains configuration settings that are applied to the database at
database and instance startup. Unauthorized changes to these parameters could lead to a
compromise of the database security posture. Oracle data and redo log files contain the data and
transaction information that support the database use. Unauthorized access to these files
bypasses access controls defined and enforced by the DBMS itself and can lead to a loss of
confidentiality and integrity.
Default
Finding
Access to sensitive data is not restricted to authorized users identified by the Information Owner.
Details:
Documentable: No
Documentable
Explanation:
8/19/2010
VL05
Page 50 of 130

References:
ECAN-1
Checks:
Review file permissions defined for critical files.

Review the file permissions on the Binary initialization parameter file (the default name is spfile
[SID].ora).
Binary initialization parameter files are by default located in the $ORACLE_HOME/dbs directory
(UNIX) or %ORACLE_HOME%\database directory (Windows).
From SQL*Plus:
select value from v$parameter where name = 'spfile';
select member from v$logfile;
select name from v$datafile;
select name from v$controlfile;
Check directory and file permissions for the files returned by the SQL commands above, for the
files located in the $ORACLE_HOME/network/admin directory (UNIX) or %ORACLE_HOME%
\network\admin directory (Windows) and the directory specified by the TNS_ADMIN environment
variable, if defined.
On UNIX systems:
ls ld [pathname]
If permissions are granted for world access, this is a Finding.
If any groups that include members other than the Oracle process and software owner accounts,
DBAs, auditors, or backup accounts are listed, this is a Finding.
On Windows Systems (From Windows Explorer):
Browse to the directory specified.
Select and right-click on the directory, select Properties, select the Security tab.
If permissions are granted to everyone, this is a Finding.
If any accounts other than the Oracle process and software owner accounts, Administrators,
DBAs, System groups, auditors, or backup accounts are listed, this is a Finding.
Fixes:
Set UNIX permissions on critical files to 640 or more restrictive.
Check group membership of the group assigned access permissions to the database software to
verify all members are authorized to have the assigned access.
Set Windows permissions to Full Control assigned to the Administrators, the Oracle service
account and DBAs.
Remove any unauthorized account access.

STIG ID:
DG0123
8/19/2010
VL05
Release Number:
Status:
Short Name:
Long Name:
Page 51 of 130
4
Active
DBMS Administrative data access
Access to DBMS system tables and other configuration or metadata should be restricted to DBAs.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
DG0123-ORACLE11
Category II
System tables and DBA views contain information such as user, system and data that could lead to
unauthorized access. Revoke any privileges granted to non-DBA accounts that provide direct
access to objects owned by SYS or access to DBA views (DBA_%).
Access to DBMS system tables and other configuration or metadata is not restricted to DBAs.
Yes
Review the accounts, privileges, object owners and objects as generated. Confirm the account(s)
and privilege assignments to the objects are documented, authorized and accept as Documentable
in VMS.
References:
ECAN-1
Checks:
select grantee, privilege, owner, table_name from dba_tab_privs
where (owner='SYS' or table_name like 'DBA_%')
and privilege <> 'EXECUTE'
and grantee not in
('PUBLIC', 'AQ_ADMINISTRATOR_ROLE', 'AQ_USER_ROLE',
'AURORA$JIS$UTILITY$', 'OSE$HTTP$ADMIN', 'TRACESVR',
'CTXSYS', 'DBA', 'DELETE_CATALOG_ROLE',
'EXECUTE_CATALOG_ROLE', 'EXP_FULL_DATABASE',
'GATHER_SYSTEM_STATISTICS', 'HS_ADMIN_ROLE',
'IMP_FULL_DATABASE', 'LOGSTDBY_ADMINISTRATOR', 'MDSYS',
'ODM', 'OEM_MONITOR', 'OLAPSYS', 'ORDSYS', 'OUTLN',
'RECOVERY_CATALOG_OWNER', 'SELECT_CATALOG_ROLE',
'SNMPAGENT', 'SYSTEM', 'WKSYS', 'WKUSER', 'WMSYS',
8/19/2010
VL05
Page 52 of 130
'WM_ADMIN_ROLE', 'XDB', 'LBACSYS', 'PERFSTAT', 'XDBADMIN')

and grantee not in
order by grantee;
If no accounts or roles are listed, this is not a Finding.
Verify that accounts/roles listed have been authorized by the IAO.
NOTE: Any accounts created and assigned privileges by Oracle product installations do not
require authorization by the IAO. The exclusion list provided in this check is subject to changes or
additions made by updates to Oracle products. Non-Oracle products should not be assigned
access to Oracle system data and tables, however, if required, document requirement in the
System Security Plan and ensure authorization by the IAO.
Fixes:
Revoke unauthorized access to system tables and data.
From SQL*Plus:
revoke [object privilege] on [system object name] from [account name or role];
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015632
DG0124
4
Active
DBA account use
Use of DBA accounts should be restricted to administrative activities.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DG0124-ORACLE11
Category II
Use of privileged accounts for non-administrative purposes puts data at risk of unintended or
unauthorized loss, modification or exposure. In particular, DBA accounts if used for nonadministration application development or application maintenance can lead to miss-assignment of
privileges where privileges are inherited by object owners. It may also lead to loss or compromise of
application data where the elevated privileges bypass controls designed in and provided by
applications.
Default
8/19/2010
VL05
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Page 53 of 130
Use of DBA accounts is not restricted to administrative activities.

No

Department of Defense (DOD) Instruction 8500.2, Information Assurance (IA) Implementation ECLP1
Review objects owned by custom DBA user accounts.
If any objects owned by DBA accounts are accessed by non-DBA users either directly or indirectly
by other applications, this is a Finding.
Review documentation or instructions provided to DBAs to communicate proper and improper use
of DBA accounts.
If such documentation does not exist or if DBAs do not indicate an understanding of this
Fixes:
Develop, document and implement policy and procedures for outlining the proper and improper
use of DBA accounts.
The documentation should clearly state that DBA accounts are used to administer and maintain
the database only.
DBA accounts are not to be used to create or alter application objects.
Application maintenance should always be performed by the application object owner or
application administrator accounts.
Request acknowledgement of receipt of these restrictions by all users granted DBA
responsibilities.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015153
DG0125
6
Active
DBMS account password expiration
DBMS account passwords should be set to expire every 60 days or more frequently.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
8/19/2010
VL05
Page 54 of 130
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0125-ORACLE11
Category II
The PASSWORD_LIFE_TIME value specifies the length of time the same password may be used
to authenticate to a database account. After the time period specified has passed for the assigned
password, the user is required to change their password or else forfeit access to the database.
Frequent password changes help to decrease the likelihood or duration of a password compromise
that would result in unauthorized access.
DBMS account passwords are not set to expire every 60 days or more frequently.
Yes
Review the profile and limit as generated. Confirm the limits returned are documented, authorized
and accept as Documentable in VMS.
NOTE: Use of authentication via certificate or CAC for Oracle accounts makes the accounts noninteractive for the purposes of this check.
The DEFAULT profile is required to have a password lifetime set not to exceed 60 days, which is
the current password lifetime limit per DoD policy.
Custom profiles for non-interactive accounts (accounts used by applications or other systems)
may have PASSWORD_LIFE_TIME set to a time greater than 60 days, but must still have a limit
assigned.
Limits of one year or less for non-interactive accounts require IAO authorization and should be set
to a lifetime as low as administration and operation of the application will support.
From SQL*Plus:
select profile, limit
from dba_profiles,
(select limit as def_pwd_life_tm
from dba_profiles
where profile = 'DEFAULT'
and resource_name = 'PASSWORD_LIFE_TIME')
where resource_name = 'PASSWORD_LIFE_TIME'
and ((replace(limit, 'DEFAULT', def_pwd_life_tm) in
('UNLIMITED', NULL))
or (lpad(replace(limit, 'DEFAULT', def_pwd_life_tm),40,'0') >
lpad('60',40,'0')));
If the DEFAULT profile has a value greater than 60 days, this is a Finding.
If any non-default profiles have password lifetimes greater than 60 days and are assigned to
interactive accounts, this is a Finding.
8/19/2010
VL05
Page 55 of 130
If any non-default profiles have password lifetimes greater than 365 days (1 year) and are
assigned to any accounts, this is a Finding.
If any profiles have PASSWORD_LIFE_TIME set to UNLIMITED, NULL or no value, this is a
Finding.
Verify in the System Security Plan that all accounts assigned to profiles with a password lifetime
greater than 60 days belong to non-interactive accounts.
Fixes:
Assign a password lifetime of 60 days or less to the default database profile.
Assign a password lifetime of 60 days or less to non-default profiles assigned to interactive
database accounts.
Assign as password lifetime of 365 days or less to non-default profiles assigned to non-interactive
database accounts that do not support frequent password changes.
Include a list of all database accounts and their profile assignments in the System Security Plan.
Modify profiles to assign a password lifetime.
From SQL*Plus:
alter profile default limit password_life_time 60;
alter profile [profile name] limit password_life_time [60 to 365];
Replace [profile name] with any existing, non-default profile name and [60 to 365] with a value
between 60 and 365 (days) inclusive.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015633
DG0126
4
Active
DBMS account password reuse
Password reuse should be prevented where supported by the DBMS.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
DG0126-ORACLE11
Category II
Severity
8/19/2010
VL05
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Page 56 of 130
Password reuse restrictions protect against bypass of password expiration requirements and help
protect accounts from password guessing attempts. The DoDI 8500.2 specifies preventing
password reuse to the extent system capabilities permit. The PASSWORD_REUSE_MAX value
specifies the number of password changes before a password can be reused. The
PASSWORD_REUSE_TIME value specifies the length of time before a password can be reused.
Password reuse is not prevented where supported by the DBMS.
No
If no DBMS accounts authenticate using passwords, this check is Not a Finding.
Review DBMS account password reuse restrictions:
From SQL*Plus:
select p1.profile profile, p1.limit REUSE_MAX, p2.limit REUSE_TIME
from dba_profiles p1, dba_profiles p2
where p1.profile = p2.profile
and p1.resource_name = 'PASSWORD_REUSE_MAX'
and p2.resource_name = 'PASSWORD_REUSE_TIME'
order by p1.profile;
If limits for REUSE_MAX and REUSE_TIME are set to UNLIMITED, this is a Finding.
If limits for REUSE_MAX and REUSE_TIME are set to values, this is a Finding.
NOTE: If limits for REUSE_MAX or REUSE_TIME are set to DEFAULT refer to the corresponding
limits set for the DEFAULT profile.
If the DBMS uses Host Authentication, confirm that the host is configured to prevent password
reuse. If it is not, this is a Finding.
Fixes:
Configure the DBMS to prevent password reuse by modifying Oracle profiles:
From SQL*Plus:
password_reuse_max 10
password_reuse_time UNLIMITED;
alter profile [profile name] limit
password_reuse_max default
password_reuse_time default;
Replace [profile name] with any existing, non-default profile names.
Where Host Authentication is used, configure the OS to prevent password reuse.
Consider configuring the DBMS to use alternate authentication methods other than password
authentication where supported by the DBMS.
8/19/2010
VL05
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
Page 57 of 130
V0015634
DG0127
7
Active
DBMS account password easily guessed
DBMS account passwords should not be set to easily guessed words or values.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0127-ORACLE11
Category II
DBMS account passwords set to common dictionary words or values render accounts vulnerable to
password guessing attacks and unauthorized access.
DBMS account passwords are set to easily guessed words or values.
No
If no DBMS accounts authenticate using passwords (rare), this check is Not a Finding.
Confirm that database profiles specify a password verify function.
From SQL*Plus:
select distinct limit from dba_profiles
where resource_name= 'PASSWORD_VERIFY_FUNCTION'
order by limit;
Review the code for the password verify function or have the DBA demonstrate a password
8/19/2010
VL05
Page 58 of 130
change to ensure that the function does not accept passwords that are the same as the
username, the name of the database or instance name.
If reviewing code, logic similar to the following should be discovered:
-- Check if the password is too simple. A dictionary of words may be
-- maintained and a check may be made so as not to allow the words
-- that are too simple for the password.
if nls_lower(password) in
('welcome','database','account','user','password','oracle','computer','abcdefgh',
'12345') then
raise_application_error(-20002, 'Password too simple');
end if;
If any password_verify_function routines do not check for simple passwords, this is a Finding.
Check also to ensure all password-authenticated accounts specify a password_verify_function.
From SQL*Plus:
select distinct profile from dba_profiles
and (limit is NULL or limit = NULL);
If any profiles are returned that are used by password-authenticated accounts, this is a Finding.
To view the names of password-authenticated accounts:
From SQL*Plus:
select name from user$ where password is not NULL;
Fixes:
Define and apply a Password Verify Function for all profiles where passwords are used to
authenticate accounts.
See Fix information for DG0079 to create a Password Verify Function that meets STIG
requirements.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015635
DG0128
4
Active
DBMS default passwords
DBMS default accounts should be assigned custom passwords.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
8/19/2010
VL05
Page 59 of 130
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0128-ORACLE11
Category I
If all of the accounts listed show an account status of LOCKED & EXPIRED or LOCKED this is a
Finding, but downgrade the severity Category Code to II.
Oracle databases have several well-known default username/password combinations. Default
passwords may provide unauthorized access to the server. Default accounts should be locked and
expired when they are not required for daily operations. This finding is a Category I severity because
the fully privileged Database Administrator accounts SYS and SYSTEM have well known default
passwords and these accounts provide full access to the database.
DBMS default accounts have not been assigned custom passwords.
No
From SQL*Plus:
select decode(type#,0,'ROLE',1,'USER') type, name,
decode(astatus,
0,'OPEN',
1,'EXPIRED',
2,'EXPIRED(GRACE)',
4,'LOCKED(TIMED)',
8,'LOCKED',
5,'EXPIRED and LOCKED(TIMED)',
6,'EXPIRED(GRACE) and LOCKED(TIMED)',
9,'EXPIRED and LOCKED',
10,'EXPIRED(GRACE) and LOCKED') account_status
from sys.user$
where user$.name <> 'XS$NULL'
and password = decode(name,
'AASH','9B52488370BB3D77','ABA1','30FD307004F350DE','ABM','D0F2982F121C7840','AD_MO
NITOR','54F0C83F51B03F49','ADAMS','72CDEF4A3483F60D','ADS','D23F0F5D871EB69F','ADS
EUL_US','4953B2EB6FCB4339','AHL','7910AE63C9F7EEEE','AHM','33C2E27CF5E401A4','AK','8
FCB78BBA8A59515','AL','384B2C568DE4C2B5','ALA1','90AAC5BD7981A3BA','ALLUSERS','42F
7CD03B7D2CA0F','ALR','BE89B24F9F8231A9','AMA1','585565C23AB68F71','AMA2','37E458EE1
688E463','AMA3','81A66D026DC5E2ED','AMA4','194CCC94A481DCDE','AMF','EC9419F55CDC6
66B','AMS','BD821F59270E5F34','AMS1','DB8573759A76394B','AMS2','EF611999C6AD1FD7','A
MS3','41D1084F3F966440','AMS4','5F5903367FFFB3A3','AMSYS','4C1EF14ECE13B5DE','AMV','
38BC87EB334A1AC4','AMW','0E123471AACA2A62','ANNE','1EEA3E6F588599A6','ANONYMOU
S','94C33111FD9C66F3','AOLDEMO','D04BBDD5E643C436','AP','EED09A552944B6AD','APA1','
D00197BF551B2A79','APA2','121C6F5BD4674A33','APA3','5F843C0692560518','APA4','BF2122
7532D2794A','APPLEAD','5331DB9C240E093B','APPLSYS','0F886772980B8C79','APPLSYSPUB
','D2EEF40EE87221E','APPLSYS','E153FFF4DAE6C9F7','APPS','D728438E8A5925E0','APS1','F
65751C55EA079E6','APS2','5CACE7B928382C8B','APS3','C786695324D7FB3B','APS4','F86074
C4F4F82D2C','AQDEMO','5140E342712061DD','AQJAVA','8765D2543274B42E','AQUSER','4CF
13BDAC1D7511C','AR','BBBFE175688DED7E','ARA1','4B9F4E0667857EB8','ARA2','F4E52BFBE
8/19/2010
VL05
Page 60 of 130
D4652CD','ARA3','E3D8D73AE399F7FE','ARA4','758FD31D826E9143','ARS1','433263ED08C7A4
FD','ARS2','F3AF9F26D0213538','ARS3','F6755F08CC1E7831','ARS4','452B5A381CABB241','AR
T','665168849666C4F3','ASF','B6FD427D08619EEE','ASG','1EF8D8BD87CF16BE','ASL','03B20D
2C323D0BFE','ASN','1EE6AEBD9A23D4E0','ASO','F712D80109E3C9D8','ASP','CF95D2C6C85F
F513','AST','F13FF949563EAB3C','AUC_GUEST','8A59D349DAEC26F7','AURORA$ORB$UNAU
THENTICATED','80C099F0EADF877E','AUTHORIA','CC78120E79B57093','AX','0A8303530E86F
CDD','AZ','AAA18B5D51B0D5AC','B2B','CC387B24E013C616','BAM','031091A1D1A30061','BCA1
','398A69209360BD9D','BCA2','801D9C90EBC89371','BEN','9671866348E03616','BIC','E84CC95
CBBAC1B67','BIL','BF24BCE2409BE1F7','BIM','6026F9A8A54B9468','BIS','7E9901882E5F3565','
BIV','2564B34BE50C2524','BIX','3DD36935EAEDE2E3','BLAKE','9435F2E60569158E','BMEADO
WS','2882BA3D3EE1F65A','BNE','080B5C7EE819BF78','BOM','56DB3E89EAE5788E','BP01','612
D669D2833FACD','BP02','FCE0C089A3ECECEE','BP03','0723FFEEFBA61545','BP04','E5797698
E0F8934E','BP05','58FFC821F778D7E9','BP06','2F358909A4AA6059','BSC','EC481FD7DCE6366
A','BUYACCT','D6B388366ECF2F61','BUYAPPR1','CB04931693309228','BUYAPPR2','3F98A3AD
C037F49C','BUYAPPR3','E65D8AD3ACC23DA3','BUYER','547BDA4286A2ECAE','BUYMTCH','0
DA5E3B504CC7497','CAMRON','4384E3F9C9C9B8F1','CANDICE','CF458B3230215199','CARL','
99ECCC664FFDFEA2','CARLY','F7D90C099F9097F1','CARMEN','46E23E1FD86A4277','CARRIE
CONYERS','9BA83B1E43A5885B','CATADMIN','AF9AB905347E004F','CE','E7FDFE26A524FE39'
,'CEASAR','E69833B8205D5DD7','CENTRA','63BF5FFE5E3EA16D','CFD','667B018D4703C739','
CHANDRA','184503FA7786C82D','CHARLEY','E500DAA705382E8D','CHRISBAKER','52AFB6B3
BE485F81','CHRISTIE','C08B79CCEC43E798','CINDY','3AB2C717D1BD0887','CLARK','7AAFE7
D01511D73F','CLAUDE','C6082BCBD0B69D20','CLARK','74DF527800B6D713','CLINT','163FF8C
CB7F11691','CLN','A18899D42066BFCA','CN','73F284637A54777D','CNCADMIN','C7C8933C678
F7BF9','CONNIE','982F4C420DD38307','CONNOR','52875AEB74008D78','CORY','93CE4CCE63
2ADCD2','CRM1','6966EA64B0DFC44E','CRM2','B041F3BEEDA87F72','CRP','F165BDE5462AD5
57','CRPB733','2C9AB93FF2999125','CRPCTL','4C7A200FB33A531D','CRPDTA','6665270166D6
13BC','CS','DB78866145D4E1C3','CSADMIN','94327195EF560924','CSAPPR1','47D841B5A0116
8FF','CSC','EDECA9762A8C79CD','CSD','144441CEBAFC91CF','CSDUMMY','7A587C459B93AC
E4','CSE','D8CC61E8F42537DA','CSF','684E28B3C899D42C','CSI','71C2B12C28B79294','CSL','
C4D7FE062EFB85AB','CSM','94C24FC0BE22F77F','CSMIG','09B4BB013FBD0D65','CSP','5746C
5E077719DB4','CSR','0E0F7C1B1FE3FA32','CSS','3C6B8C73DDC6B04F','CTXDEMO','CB6B5E9
D9672FE89','CTXSYS','24ABAB8B06281B4C','CTXTEST','064717C317B551B6','CTXSYS','71E6
87F036AD56E5','CUA','CB7B2E6FFDD7976F','CUE','A219FE4CA25023AA','CUF','82959A9BD2D
51297','CUG','21FBCADAEAFCC489','CUI','AD7862E01FA80912','CUN','41C2D31F3C85A79D','C
UP','C03082CD3B13EC42','CUS','00A12CC6EBF8EDB8','CZ','9B667E9C5A0D21A6','DAVIDMOR
GAN','B717BAB262B7A070','DBSNMP','E066D214D5421CCC','DCM','45CCF86E1058D3A5','DD
7333','44886308CF32B5D4','DD7334','D7511E19D9BD0F90','DD810','0F9473D8D8105590','DD8
11','D8084AE609C9A2FD','DD812','AB71915CF21E849E','DD9','E81821D03070818C','DDB733','
7D11619CEE99DE12','DDD','6CB03AF4F6DD133D','DEMO8','0E7260738FDFD678','DES','ABFE
C5AC2274E54D','DES2K','611E7A73EC4B425A','DEV2000_DEMOS','18A0C8BD6B13BEE2','DE
VB733','7500DF89DC99C057','DEVUSER','C10B4A80D00CA7A5','DGRAY','5B76A1EB8F212B85
','DIP','CE4A36B8E06CA59C','DISCOVERER5','AF0EDB66D914B731','DKING','255C2B0E1F091
2EA','DLD','4454B932A1E0E320','DMADMIN','E6681A8926B40826','DMATS','8C692701A453128
6','DMS','1351DC7ED400BD59','DMSYS','BFBA5A553FD9E28A','DOM','51C9F2BECA78AE0E','D
POND','79D6A52960EEC216','DSGATEWAY','6869F3CFD027983A','DV7333','36AFA5CD674BA
841','DV7334','473B568021BDB428','DV810','52C38F48C99A0352','DV811','B6DC5AAB55ECB66
C','DV812','7359E6E060B945BA','DV9','07A1D03FD26E5820','DVP1','0559A0D3DE0759A6','EAA'
,'A410B2C5A0958CDF','EAM','CE8234D92FCFB563','EC','6A066C462B62DD46','ECX','0A306451
83812087','EDR','5FEC29516474BB3A','EDWEUL_US','5922BA2E72C49787','EDWREP','79372B
4AB748501F','EGC1','D78E0F2BE306450D','EGD1','DA6D6F2089885BA6','EGM1','FB949D5E4B
5255C0','EGO','B9D919E5F5A9DA71','EGR1','BB636336ADC5824A','END1','688499930C210B75
','ENG','4553A3B443FB3207','ENI','05A92C0958AFBCBC','ENM1','3BDABFD1246BFEA2','ENS1','
F68A5D0D6D2BB25B','ENTMGR_CUST','45812601EAA2B8BD','ENTMGR_PRO','200026829914
70B3','ENTMGR_TRAIN','BE40A3BE306DD857','EOPP_PORTALADM','B60557FD8C45005A','E
OPP_PORTALMGR','9BB3CF93F7DE25F1','EOPP_USER','13709991FC4800A1','EUL_US','28AE
C22561414B29','EVM','137CEDC20DE69F71','EXA1','091BCD95EE112EE3','EXA2','E4C0A21DB
D06B890','EXA3','40DC4FA801A73560','EXA4','953885D52BDF5C86','EXFSYS','66F4EF5650C2
0355','EXS1','C5572BAB195817F0','EXS2','8FAA3AC645793562','EXS3','E3050174EE1844BA','E
XS4','E963BFE157475F7D','FA','21A837D0AED8F8E5','FEM','BD63D79ADF5262E7','FIA1','2EB7
6E07D3E094EC','FII','CF39DE29C08F71B9','FLM','CEE2C4B59E7567A3','FNI1','308839029D04F
80C','FNI2','05C69C8FEAB4F0B9','FPA','9FD6074B9FD3754C','FPT','73E3EC9C0D1FAECF','FR
M','9A2A7E2EBE6E4F71','FTA1','65FF9AB3A49E8A13','FTE','2FB4D2C9BAE2CCCA','FUN','8A7
055CA462DB219','FV','907D70C0891A85B1','FVP1','6CC7825EADF994E8','GALLEN','F8E8ED9F
15842428','GCA1','47DA9864E018539B','GCA2','FD6E06F7DD50E868','GCA3','4A4B9C2E9624C
8/19/2010
VL05
Page 61 of 130
410','GCA9','48A7205A4C52D6B5','GCMGR1','14A1C1A08EA915D6','GCMGR2','F4F11339A422
1A4D','GCMGR3','320F0D4258B9D190','GCS','7AE34CA7F597EBF7','GCS1','2AE8E84D2400E6
1D','GCS2','C242D2B83162FF3D','GCS3','DCCB4B49C68D77E2','GEORGIAWINE','F05B1C50A1
C926DE','GL','CD6E99DACE4EA3A6','GLA1','86C88007729EB36F','GLA2','807622529F170C02','
GLA3','863A20A4EFF7386B','GLA4','DB882CF89A758377','GLS1','7485C6BD564E75D1','GLS2','
319E08C55B04C672','GLS3','A7699C43BB136229','GLS4','7C171E6980BE2DB9','GM_AWDA','4
A06A107E7A3BB10','GM_COPI','03929AE296BAAFF2','GM_DPHD','0519252EDF68FA86','GM_
MLCT','24E8B569E8D1E93E','GM_PLADMA','2946218A27B554D8','GM_PLADMH','2F6EDE9631
3AF1B7','GM_PLCCA','7A99244B545A038D','GM_PLCCH','770D9045741499E6','GM_PLCOMA','
91524D7DE2B789A8','GM_PLCOMH','FC1C6E0864BF0AF2','GM_PLCONA','1F531397B19B1E0
5','GM_PLCONH','C5FE216EB8FCD023','GM_PLNSCA','DB9DD2361D011A30','GM_PLNSCH','C
80D557351110D51','GM_PLSCTA','3A778986229BA20C','GM_PLSCTH','9E50865473B63347','G
M_PLVET','674885FDB93D34B9','GM_SPO','E57D4BD77DAF92F0','GM_STKH','C498A86BE266
3899','GMA','DC7948E807DFE242','GMD','E269165256F22F01','GME','B2F0E221F45A228F','GM
F','A07F1956E3E468E1','GMI','82542940B0CF9C16','GML','5F1869AD455BBA73','GMP','450793
ACFCC7B58E','GMS','E654261035504804','GR','F5AB0AA3197AEE42','GUEST','1C0A090E404C
ECD0','HCC','25A25A7FEFAC17B6','HHCFO','62DF37933FB35E9F','HR','4C6D73C3E8B0F0DA','
HRI','49A3A09B8FC291D0','HXC','4CEA0BF02214DA55','HXT','169018EB8E2C4A77','IA','42C7E
AFBCEEC09CC','IBA','0BD475D5BF449C63','IBC','9FB08604A30A4951','IBE','9D41D2B3DD0952
27','IBP','840267B7BD30C82E','IBU','0AD9ABABC74B3057','IBY','F483A48F6A8C51EC','ICX','776
6E887AF4DCC46','IEB','A695699F0F71C300','IEC','CA39F929AF0A2DEC','IEM','37EF7B2DD172
79B5','IEO','E93196E9196653F1','IES','30802533ADACFE14','IEU','5D0E790B9E882230','IEX','6C
C978F56D21258D','IGC','D33CEB8277F25346','IGF','1740079EFF46AB81','IGI','8C69D50E9D92
B9D0','IGS','DAF602231281B5AC','IGW','B39565F4E3CF744B','IMC','C7D0B9CDE0B42C73','IMT
','E4AAF998653C9A72','INS1','2ADC32A0B154F897','INS2','EA372A684B790E2A','INTERNET_A
PPSERVER_REGISTRY','A1F98A977FFD73CD','INV','ACEAB015589CF4BC','IP','D29012C144B
58A40','IPA','EB265A08759A15B4','IPD','066A2E3072C1F2F3','ISC','373F527DC0CFAE98','ISTE
WARD','8735CA4085DE3EEA','ITG','D90F98746B68E6CA','JA','9AC2B58153C23F3D','JD7333','F
B5B8A12AE623D52','JD7334','322810FCE43285D9','JD9','9BFAEC92526D027B','JDE','7566DC9
52E73E869','JDEDBA','B239DD5313303B1D','JE','FBB3209FD6280E69','JG','37A99698752A1CF
1','JL','489B61E488094A8D','JOHNINARI','B3AD4DA00F9120CE','JONES','B9E99443032F059D','
JTF','5C5F6FC2EBB94124','JTI','B8F03D3E72C96F7','JTM','6D79A2259D5B4B5A','JTR','B4E2BE
38B556048F','JTS','4087EE6EB7F9CD7C','JUNK_PS','BBC38DB05D2D3A7A','JUSTOSHUM','53
369CD63902FAAA','KELLYJONES','DD4A3FF809D2A6CF','KEVINDONS','7C6D9540B45BBC39',
'KPN','DF0AED05DE318728','LADAMS','AE542B99505CDCD2','LBA','18E5E15A436E7157','LBA
CSYS','AC9700FD3F1410EB','LDQUAL','1274872AB40D4FCD','LHILL','E70CA2CA0ED555F5','L
NS','F8D2BC61C10941B2','LQUINCY','13F9B9C1372A41B6','LSA','2D5E6036E3127B7E','MDDA
TA','DF02A496267DEE66','MDSYS','72979A94BAD2AF80','ME','E5436F7169B29E4D','MDSYS','9
AAEB2214DCC9A31','MFG','FC1B0DD35E790847','MGR1','E013305AB0185A97','MGR2','5ADE3
58F8ACE73E8','MGR3','05C365C883F1251A','MGR4','E229E942E8542565','MIKEIKEGAMI','AAF
7A168C83D5C47','MJONES','EE7BB3FEA50A21C5','MLAKE','7EC40274AC1609CA','MM1','4418
294570E152E7','MM2','C06B5B28222E1E62','MM3','A975B1BD0C093DA3','MM4','88256901EB0
3A012','MM5','4CEA62CBE776DCEC','MMARTIN','D52F60115FE87AA4','MOBILEADMIN','25392
2686A4A45CC','MRP','B45D4DF02D4E0C85','MSC','89A8C104725367B2','MSD','6A29482069E2
3675','MSO','3BAA3289DB35813C','MSR','C9D53D00FE77D813','MST','A96D2408F62BE1BC','M
WA','1E2F06BE2A1D41A6','NEILKATSU','1F625BB9FEBC7617','OBJ7333','D7BDC9748AFEDB5
2','OBJ7334','EB6C5E9DB4643CAC','OBJB733','61737A9F7D54EF5F','OCA','9BC450E4C656949
2','ODM','C252E8FA117AF049','ODM_MTR','A7A32CD03D3CE8D5','ODS','89804494ADFC71BC'
,'ODSCOMMON','59BBED977430C1A8','OE','D1A2DFC623FDA40A','OKB','A01A5F0698FC9E31'
,'OKC','31C1DDF4D5D63FE6','OKE','B7C1BB95646C16FE','OKI','991C817E5FD0F35A','OKL','DE
058868E3D2B966','OKO','6E204632EC7CA65D','OKR','BB0E28666845FCDC','OKS','C2B4C76A
B8257DF5','OKX','F9FDEB0DE52F5D6B','OL810','E2DA59561CBD0296','OL811','B3E88767A014
03F8','OL812','AE8C7989346785BA','OL9','17EC83E44FB7DB5B','OLAPSYS','3FB8EF9DB53864
7C','ONT','9E3C81574654100A','OPI','1BF23812A0AEEDA0','ORABAM','D0A4EA93EF21CE25','
ORABAMSAMPLES','507F11063496F222','ORABPEL','26EFDE0C9C051988','ORAESB','CC7FC
CB3A1719EDA','ORAOCA_PUBLIC','FA99021634DDC111','ORASAGENT','234B6F4505AD8F25',
'ORASSO','F3701A008AA578CF','ORASSO_DS','17DC8E02BC75C141','ORASSO_PA','133F8D1
61296CB8F','ORASSO_PS','63BB534256053305','ORASSO_PUBLIC','C6EED68A8F75F5D3','OR
DPLUGINS','88A2B2C183431F00','ORDSYS','7EFA02EC7EA6B86F','OSM','106AE118841A5D8C
','OTA','F5E498AC7009A217','OUTLN','4A3BA55E08595C81','OWAPUB','6696361B64F9E0A9','O
WF_MGR','3CBED37697EB01D1','OZF','970B962D942D0C75','OZP','B650B1BB35E86863','OZS'
,'0DABFF67E0D33623','PA','8CE2703752DB36D8','PABLO','5E309CB43FE2C2FF','PAIGE','02B6
B704DFDCE620','PAM','1383324A0068757C','PARRISH','79193FDACFCE46F6','PARSON','AE28
B2BD64720CD7','PAT','DD20769D59F4F7BF','PATORILY','46B7664BD15859F9','PATRICKSANC
8/19/2010
VL05
Page 62 of 130
HEZ','47F74BD3AD4B5F0A','PATSY','4A63F91FEC7980B7','PAUL','35EC0362643ADD3F','PAUL
A','BB0DC58A94C17805','PAXTON','4EB5D8FAD3434CCC','PCA1','8B2E303DEEEEA0C0','PCA
2','7AD6CE22462A5781','PCA3','B8194D12FD4F537D','PCA4','83AD05F1D0B0C603','PCS1','2B
E6DD3D1DEA4A16','PCS2','78117145145592B1','PCS3','F48449F028A065B1','PCS4','E1385509
C0B16BED','PD7333','5FFAD8604D9DC00F','PD7334','CDCF262B5EE254E1','PD810','EB04A17
7A74C6BCB','PD811','3B3C0EFA4F20AC37','PD812','E73A81DB32776026','PD9','CACEB3F9EA
16B9B7','PDA1','C7703B70B573D20F','PEARL','E0AFD95B9EBD0261','PEG','20577ED9A8DB8D
22','PENNY','BB6103E073D7B811','PEOPLE','613459773123B38A','PERCY','EB9E8B33A2DDFD
11','PERRY','D62B14B93EE176B6','PETE','4040619819A9C76E','PEYTON','B7127140004677FC'
,'PHIL','181446AE258EE2F6','PJI','5024B1B412CD4AB9','PJM','021B05DBB892D11F','PM','72E3
82A52E89575A','PMI','A7F7978B21A6F65E','PN','D40D0FEF9C8DC624','PO','355CBEC355C10F
EF','POA','2AB40F104D8517A0','POLLY','ABC770C112D23DBE','POM','123CF56E05D4EF3C','P
ON','582090FD3CC44DA3','PORTAL','A96255A27EC33614','PORTAL_APP','831A79AFB0BD29E
C','PORTAL_DEMO','A0A3A6A577A931A3','PORTAL_PUBLIC','70A9169655669CE8','PORTAL30
','969F9C3839672C6D','PORTAL30_DEMO','CFD1302A7F832068','PORTAL30_PUBLIC','420682
01613CA6E2','PORTAL30_SSO','882B80B587FCDBC8','PORTAL30_SSO_PS','F2C3DC8003BC
90F8','PORTAL30_SSO_PUBLIC','98741BDA2AC7FFB2','POS','6F6675F272217CF7','PPM1','AA
4AE24987D0E84B','PPM2','4023F995FF78077C','PPM3','12F56FADDA87BBF9','PPM4','84E17C
B7A3B0E769','PPM5','804C159C660F902C','PRISTB733','1D1BCF8E03151EF5','PRISTCTL','785
62A983A2F78FB','PRISTDTA','3FCBC379C8FE079C','PRODB733','9CCD49EB30CB80C4','PRO
DCTL','E5DE2F01529AE93C','PRODDTA','2A97CD2281B256BA','PRODUSER','752E503EFBF2C
2CA','PROJMFG','34D61E5C9BC7147E','PRP','C1C4328F8862BC16','PS','0AE52ADF439D30BD'
,'PS810','90C0BEC7CA10777E','PS810CTL','D32CCE5BDCD8B9F9','PS810DTA','AC0B7353A58
FC778','PS811','B5A174184403822F','PS811CTL','18EDE0C5CCAE4C5A','PS811DTA','7961547
C7FB96920','PS812','39F0304F007D92C8','PS812CTL','E39B1CE3456ECBE5','PS812DTA','3780
281C933FE164','PSA','FF4B266F9E61F911','PSB','28EE1E024FC55E66','PSBASS','F739804B71
8D4406','PSEM','40ACD8C0F1466A57','PSFT','7B07F6F3EC08E30D','PSFTDBA','E1ECD83073C
4E134','PSP','4FE07360D435E2F0','PTADMIN','4C35813E45705EBA','PTCNE','463AEFECBA55
BEE8','PTDMO','251D71390034576A','PTE','380FDDB696F0F266','PTESP','5553404C13601916',
'PTFRA','A360DAD317F583E3','PTG','7AB0D62E485C9A3D','PTGER','C8D1296B4DF96518','PTJ
PN','2159C2EAF20011BF','PTUKE','D0EF510BCB2992A3','PTUPG','2C27080C7CC57D06','PTW
EB','8F7F509D4DC01DF6','PTWEBSERVER','3C8050536003278B','PUBLIC','','PV','76224BCC80
895D3D','PY7333','2A9C53FE066B852F','PY7334','F3BBFAE0DDC5F7AC','PY810','95082D35E9
4B88C2','PY811','DC548D6438E4D6B7','PY812','99C575A55E9FDA63','PY9','B8D4E503D0C4FC
FD','QA','C7AEAA2D59EB1EAE','QOT','B27D0E5BA4DC8DEA','QP','10A40A72991DCA15','QRM'
,'098286E4200B22DE','QS','4603BCD2744BDE4F','QS_ADM','3990FB418162F2A0','QS_CB','870
C36D8E6CD7CF5','QS_CBADM','20E788F9D4F1D92C','QS_CS','2CA6D0FC25128CF3','QS_ES',
'9A5F2D9F5D1A9EF4','QS_OS','0EF5997DC2638A61','QS_WS','0447F2F756B4F460','RENE','9A
AD141AB0954CF0','REPADMIN','915C93F34954F5F8','REPORTS','0D9D14FE6653CF69','REPO
RTS_USER','635074B4416CD3AC','RESTRICTED_US','E7E67B60CFAFBB2D','RG','0FAA06DA0
F42F21F','RHX','FFDF6A0C8C96E676','RLA','C1959B03F36C9BB2','RLM','4B16ACDA351B557D'
,'RM1','CD43500DAB99F447','RM2','2D8EE7F8857D477E','RM3','1A95960A95AC2E1D','RM4','65
1BFD4E1DE4B040','RM5','FDCC34D74A22517C','RMAN','E7B5D92911C831E1','ROB','94405F5
16486CA24','RPARKER','CEBFE4C41BBCC306','RWA1','B07E53895E37DBBB','SALLYH','21457
C94616F5716','SAM','4B95138CB6A4DB94','SARAHMANDY','60BE21D8711EE7D9','SCM1','507
306749131B393','SCM2','CBE8D6FAC7821E85','SCM3','2B311B9CDC70F056','SCM4','1FDF372
790D5A016','SCOTT','F894844C34402B67','SDAVIS','A9A3B88C6A550559','SECDEMO','009BB
E8142502E10','SEDWARDS','00A2EDFD7835BC43','SELLCM','8318F67F72276445','SELLER','B
7F439E172D5C3D0','SELLTREAS','6EE7BA85E9F84560','SERVICES','B2BE254B514118A5','SE
TUP','9EA55682C163B9A3','SH','54B253CBBAAA8C48','SI_INFORMTN_SCHEMA','84B8CBCA4
D477FA3','SID','CFA11E6EBA79D33E','SKAYE','ED671B63BDDB6B50','SKYTETSUKA','EB5DA7
77D1F756EC','SLSAA','99064FC6A2E4BBE8','SLSMGR','0ED44093917BE294','SLSREP','847B6
AAB9471B0A5','SRABBITT','85F734E71E391DF5','SRALPHS','975601AA57CBD61A','SRAY','C2
33B26CFC5DC643','SRIVERS','95FE94ADC2B39E08','SSA1','DEE6E1BEB962AA8B','SSA2','96C
A278B20579E34','SSA3','C3E8C3B002690CD4','SSC1','4F7AC652CC728980','SSC2','A1350B32
8E74AE87','SSC3','EE3906EC2DA586D8','SSOSDK','7C48B6FF3D54D006','SSP','87470D6CE20
3FB4D','SSS1','E78C515C31E83848','SUPPLIER','2B45928C2FE77279','SVM7333','04B731B0E
E953972','SVM7334','62E2A2E886945CC8','SVM810','0A3DCD8CA3B6ABD9','SVM811','2B0CD5
7B1091C936','SVM812','778632974E3947C9','SVM9','552A60D8F84441F1','SVMB733','DD2BFB
14346146FE','SVP1','F7BF1FFECE27A834','SY810','D56934CED7019318','SY811','2FDC83B401
477628','SY812','812B8D7211E7DEF1','SY9','3991E64C4BC2EC5D','SYS','43CA255A7916ECFE'
,'SYS7333','D7CDB3124F91351E','SYS','5638228DAF52805F','SYS7334','06959F7C9850F1E3','
SYS','D4C5016086B2DC6A','SYSADMIN','DC86E8DEAA619C1A','SYSB733','7A7F5C90BEC02F
0E','SYSMAN','EB258E708132DD2D','SYSTEM','4D27CA6E3E3066E6','TDEMARCO','CAB71A14
8/19/2010
VL05
Page 63 of 130
FA426FAE','SYSTEM','D4DF7931AB130E37','TDOS_ICSAP','7C0900F751723768','TESTCTL','20
5FA8DF03A1B0A6','TESTDTA','EEAF97B5F20A3FA3','TRA1','BE8EDAE6464BA413','TRACESV
R','F9DA8977092B7B81','TRBM1','B10ED16CD76DBB60','TRCM1','530E1F53715105D0','TRDM1
','FB1B8EF14CF3DEE7','TRRM1','4F29D85290E62EBE','TWILLIAMS','6BF819CE663B8499','UD
DISYS','BF5E56915C3E1C64','VEA','D38D161C22345902','VEH','72A90A786AAE2914','VIDEO31
','2FA72981199F9B97','VIDEO4','9E9B1524C454EEDE','VIDEO5','748481CFF7BE98BB','VP1','3
CE03CD65316DBC7','VP2','FCCEFD28824DFEC5','VP3','DEA4D8290AA247B2','VP4','F4730B0F
A4F701DC','VP5','7DD67A696734AE29','VP6','45660DEE49534ADB','WAA1','CF013DC80A9CBE
E3','WAA2','6160E7A17091741A','WCRSYS','090263F40B744BD8','WEBDB','D4C4DCDD41B05A
5D','WEBSYS','54BA0A1CB5994D64','WENDYCHO','7E628CDDF051633A','WH','91792EFFCB24
64F9','WIP','D326D25AE0A0355C','WIRELESS','1495D279640E6C3A','WK_TEST','29802572EB5
47DBF','WIRELESS','EB9615631433603E','WKPROXY','AA3CB2A4D9188DDB','WKSYS','545E1
3456B7DDEA0','WMS','D7837F182995E381','WMSYS','7C9BA362F8314299','WPS','50D22B9D1
8547CF7','WSH','D4D76D217B02BD7A','WSM','750F2B109F49CC13','XDB','88D8364765FCE6A
F','XDO','E9DDE8ACFA7FE8E4','XDP','F05E53C662835FA2','XLA','2A8ED59E27D86D41','XLE','
CEEBE966CC6A3E39','XNB','03935918FA35C993','XNC','BD8EA41168F6C664','XNI','F5556156
7EF71890','XNM','92776EA17B8B5555','XNP','3D1FB783F96D1F5E','XNS','FABA49C38150455E'
,'XTR','A43EE9629FA90CAE','YCAMPOS','C3BBC657F099A10F','YSANCHEZ','E0C033C4C8CC
9D84','ZFA','742E092A27DDFB77','ZPB','CAF58375B6D06513','ZSA','AFD3BD3C7987CBB6','ZX',
'7B06550956254585','FLOWS_030000','B5C7B17C2C983E8F','FLOWS_FILES','5CDD1E40E516
FE6A','TSMSYS','3DF26A8B17D0F29F','ORACLE_OCM','6D17CF1EB1611F94','OWBSYS','610A
3C38F301776F','SPATIAL_CSW_ADMIN','093913703800E437','SPATIAL_WFS_ADMIN','32FA36
DC781579AA','SPATIAL_CSW_ADMIN_USR','1B290858DD14107E','SPATIAL_WFS_ADMIN_US
R','7117215D6BEE6E82','MGMT_VIEW','17028530E6D346B4','APEX_PUBLIC_USER','C8E264D
926F001D8','XS$NULL','DC4FCC8CB69A6733',name);
If any accounts listed show an account status of OPEN, this is a Finding.
If all of the accounts listed show an account status of LOCKED & EXPIRED or LOCKED this is a
Finding, but downgrade the severity Category Code to II.
Fixes:
Change passwords from the default.
Ensure passwords meet complexity standards outlined in STIG Requirement DG0079.
From SQL*Plus:
alter user [username] identified by [password];
Lock and expire any accounts not required for interactive access.
From SQL*Plus:
alter user [username] account lock;
alter user [username] password expire;
NOTE: Follow Oracle documentation for changing any default passwords. Some accounts require
coordinated actions in order to maintain operational status.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015637
DG0130
5
Active
DBMS passwords in batch and applic. source code
DBMS passwords should not be stored in compiled, encoded or encrypted batch jobs or compiled,
encoded or encrypted application source code.
Comments:
Not a Finding
8/19/2010
VL05
Page 64 of 130
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0130-ORACLE11
Category II
The storage of passwords in application source or batch job code that is compiled, encoded or
encrypted prevents compliance with password expiration and other management requirements as
well as provides another means for potential discovery.
DBMS passwords are stored in compiled, encoded or encrypted batch jobs or compiled, encoded or
encrypted application source code.
No
Ask the DBA to review application source code that is required by Check DG0091 to be encoded
or encrypted for database accounts used by applications or batch jobs to access the database.
Ask the DBA to review source batch job code prior to compiling, encoding or encrypting for
database accounts used by applications or the batch jobs themselves to access the database.
Ask the DBA and/or IAO to determine if the compiled, encoded or encrypted application source
code or batch jobs contain passwords used for authentication to the database.
If none of the identified compiled, encoded or encrypted application source code or batch job code
contain passwords used for authentication, this check is Not a Finding.
If any of the identified compiled, encoded or encrypted application source code or batch job code
do contain passwords used for authentication to the database, this is a Finding.
NOTE: This check only applies to application source code or batch job code that is compiled,
encoded or encrypted in a production environment. Application source code or batch job code that
is not compiled, encoded or encrypted would fall under Check DG0067 for determination of
compliance.
Fixes:
Design DBMS application code and batch job code that is compiled, encoded or encrypted to
NOT contain passwords.
8/19/2010
VL05
Page 65 of 130
Consider alternatives to using password authentication for compiled, encoded or encrypted batch
jobs and DBMS application code.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015639
DG0133
7
Active
DBMS Account lock time
Unlimited account lock times should be specified for locked accounts.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0133-ORACLE11
Category II
When no limit is imposed on failed logon attempts and accounts are not disabled after a set number
of failed access attempts, then the DBMS account is vulnerable to sustained attack. When access
attempts continue unrestricted, the likelihood of success is increased. A successful attempt results
in unauthorized access to the database.
Unlimited account lock times are not specified for locked accounts.
No
ECLO-1, ECLO-2
From SQL*Plus:
select profile, limit from dba_profiles
where resource_name = 'PASSWORD_LOCK_TIME'
and limit not in ('UNLIMITED', 'DEFAULT');
8/19/2010
VL05
Page 66 of 130
If any profiles are listed, this is a Finding.

A value of UNLIMITED means that the account is locked until it is manually unlocked.
Fixes:
Set the password_lock_time on all defined profiles to unlimited.
This will require the DBA manually to re-enable every locked account after the failed login limit has
been reached.
From SQL*Plus:
alter profile default limit password_lock_time unlimited;
alter profile [profile name] limit password_lock_time default;
Replace [profile name] with an existing, non-default profile name.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
V0015641
DG0135
8
Active
DBMS connection alert
Users should be alerted upon login of previous successful connections or unsuccessful attempts to
access their account.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
DG0135-ORACLE11
Category II
Unauthorized access to DBMS accounts may go undetected if account access is not monitored.
Authorized users may serve as a reliable party to report unauthorized use of to their account.
Users are not alerted upon login of previous successful connections or unsuccessful attempts to
access their account.
No
8/19/2010
VL05
Page 67 of 130
References:
ECLO-2
Checks:
If the database does not store or process classified data, or user accounts are prohibited from
accessing the database interactively, this check is Not a Finding.
NOTE: Per the STIG, The definition of an Interactive Database User can be considered an enduser who accesses the database interactively using tools like SQL*Plus, TOAD, etc. and not
through a mid-tier application. Your DAA has the option to consider administration accounts
(SYSDBA, SYSOPER, SCHEMA accounts and accounts assigned DBA privileges) as Interactive
Database User accounts for the purposes of this check. The definition of an Interactive Database
User should be documented in the System Security Plan.
Have the DBA perform an interactive logon test (via SQL*Plus) using a non-privileged account
(and a privileged account if privileged accounts meet this requirement) to verify display of user
access and account usage.
If the last successful and number of unsuccessful attempts since the last successful attempt are
not reported, this is a Finding.
Fixes:
Develop, document and implement an automated method to display at interactive logon the time
and date of the last successful login and the number of failed login attempts since the last
successful login for users that access the database interactively.
This may require a custom-developed logon trigger or procedure to accomplish.
NOTE: This may cause interaction/functionality problems with COTS applications not designed for
this kind of interaction.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015642
DG0138
7
Active
DBMS access to sensitive data
Access grants to sensitive data should be restricted to authorized user roles.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
8/19/2010
VL05
Page 68 of 130
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DG0138-ORACLE11
Category II
Unauthorized access to sensitive data may compromise the confidentiality of personnel privacy,
threaten national security or compromise a variety of other sensitive operations. Access controls
are best managed by defining requirements based on distinct job functions and assigning access
based on the job function assigned to the individual user.
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Access grants to sensitive data is not restricted to authorized user roles.

No
ECAN-1
If no data is identified as being sensitive or classified by the Information Owner, in the System
Security Plan or in the AIS Functional Architecture documentation, this check is Not a Finding.
if no identified sensitive or classified data requires encryption by the Information Owner in the
System Security Plan and/or AIS Functional Architecture documentation, this check is Not a
Finding.
Review data access requirements for sensitive data as identified and assigned by the Information
Owner in the System Security Plan.
Review the access controls for sensitive data configured in the database.
If the configured access controls do not match those defined in the System Security Plan, this is a
Finding.
Fixes:
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
Define, document and implement all sensitive data access controls based on job function in the
System Security Plan.
V0015644
DG0141
4
Active
DBMS access control bypass
Attempts to bypass access controls should be audited.
Comments:
Not a Finding
Not Applicable
Not Reviewed
8/19/2010
VL05
Condition:
Page 69 of 130
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0141-ORACLE11
Category II
Configuring proper auditing is critical to recording any malicious events or detecting when attacks
on the database occur. Auditing can be turned on for any SQL statement or any use of a system
privilege. Auditing can be enabled for all users (system wide) or for specific users. You may indicate
whether one audit record for each access to an object or one audit record for the entire session is
generated. You can enable auditing for commands that result in success, commands that result in
failure, or both. Not all audit options can be audited by session. Audit options set using the BY
SESSION clause for those actions that will not produce a session audit record will default to BY
ACCESS.
Attempts to bypass access controls is not audited.
No
ECAR-2, ECAR-3
From SQL*Plus:
select name from stmt_audit_option_map
where name not in
(select audit_option from dba_stmt_audit_opts)
and name not in
('ALL STATEMENTS', 'ANALYZE ANY DICTIONARY',
'CREATE DIRECTORY', 'DEBUG CONNECT ANY',
'DEBUG CONNECT USER', 'DELETE ANY TABLE',
'DELETE TABLE', 'DROP DIRECTORY',
'EXECUTE ANY LIBRARY', 'EXECUTE ANY PROCEDURE',
'EXECUTE ANY TYPE', 'EXECUTE LIBRARY',
'EXECUTE PROCEDURE', 'EXISTS', 'GRANT LIBRARY',
'INSERT ANY TABLE', 'INSERT TABLE', 'LOCK TABLE',
'NETWORK', 'OUTLINE', 'READUP', 'READUP DBHIGH',
'SELECT ANY DICTIONARY', 'SELECT ANY SEQUENCE',
'SELECT ANY TABLE', 'SELECT MINING MODEL',
'SELECT SEQUENCE', 'SELECT TABLE',
'UPDATE ANY TABLE', 'UPDATE TABLE', 'USE EDITION',
'WRITEDOWN', 'WRITEDOWN DBLOW', 'WRITEUP',
'WRITEUP DBHIGH');
If any audit options are returned, this is a Finding.
Fixes:
8/19/2010
VL05
Page 70 of 130
There are three (3) types of auditable events: 1) Use of system privileges, 2) Use of object
privileges, and 3) Issuance of statements. Activating some auditing options sometimes activates
others. For example, the use of a system privilege requires the issuance of a system command.
Auditing for use of the privilege also audits for the statement.
Configure auditing for Oracle as follows:
From SQL*Plus:
audit all by access;
audit all privileges by access;
audit alter database link by access;
audit alter java class by access;
audit alter java resource by access;
audit alter java source by access;
audit alter mining model by access;
audit alter public database link by access;
audit alter sequence by access;
audit alter table by access;
audit comment edition by access;
audit comment mining model by access;
audit comment table by access;
audit create java class by access;
audit create java resource by access;
audit create java source by access;
audit debug procedure by access;
audit drop java class by access;
audit drop java resource by access;
audit drop java source by access;
audit execute assembly;
audit exempt access policy by access;
audit exempt identity policy by access;
audit grant directory by access;
audit grant edition by access;
audit grant mining model by access;
audit grant procedure by access;
audit grant sequence by access;
audit grant table by access;
audit grant type by access;
audit sysdba by access;
audit sysoper by access;
The following SQL statements will disable audits set by the commands above that are not
required:
noaudit execute library;
audit rename on default by access;
If application objects have already been created, then the audit rename on object statement
should be issued for all application objects.
From SQL*Plus:
audit rename on [application object name] by access;
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
V0015645
DG0142
4
Active
DBMS Privileged action audit
Changes to configuration options should be audited.
8/19/2010
VL05
Page 71 of 130
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0142-ORACLE11
Category II
The AUDIT_SYS_OPERATIONS parameter is used to enable auditing of actions taken by the

user SYS. The SYS user account is a shared account by definition and holds all privileges in the
Oracle database. It is the account accessed by users connecting to the database with SYSDBA
or SYSOPER privileges.
Changes to configuration options are not audited.
No
ECAR-3
From SQL*Plus:
select value from v$parameter where name = 'audit_sys_operations';
If the value returned is FALSE, this is a Finding.
Fixes:
From SQL*Plus:
alter system set audit_sys_operations = TRUE scope = spfile;

STIG ID:
DG0145
Release Number: 4
8/19/2010
VL05
Status:
Short Name:
Long Name:
Page 72 of 130
Active
DBMS audit record content
Audit records should contain required information.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
MAC /
Confidentiality
Grid:
All Policies
Classified
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
DG0145-ORACLE11
Category II
Checks:
Review samples of the DBMS audit logs.
Complete forensically valuable data may be unavailable or accountability may be jeopardized

when audit records do not contain sufficient information.
Audit records do not contain required information.
No
ECAR-1
Compare to the required elements listed below:

- User ID.
- Successful and unsuccessful attempts to access security files
- Date and time of the event.
- Type of event.
If the elements listed above are not included in the audit logs at at minimum, this is a Finding.
Fixes:
Open
Configure audit settings to include the following list of elements in the audit logs at a minimum:
- User ID.
- Type of event.
Comments:
8/19/2010
VL05
Page 73 of 130
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
MAC /
Confidentiality
Grid:
All Policies
Classified
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
DG0145-ORACLE11
Category II
Checks:
Complete forensically valuable data may be unavailable or accountability may be jeopardized

when audit records do not contain sufficient information.
No
ECAR-2

- User ID.
- Type of event.
- Success or failure of event.
- Successful and unsuccessful logons.
- Denial of access resulting from excessive number of logon attempts.
- Blocking or blacklisting a user ID, terminal or access port, and the reason for the action.
- Activities that might modify, bypass, or negate safeguards controlled by the system.
Fixes:
- User ID.
- Type of event.
8/19/2010
VL05
Page 74 of 130
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0145-ORACLE11
Category II
Complete forensically valuable data may be unavailable or accountability may be jeopardized when
audit records do not contain sufficient information.
No
ECAR-3
- User ID.
- Type of event.
- Data required to audit the possible use of covert channel mechanisms.
- Privileged activities and other system-level access.
- Starting and ending time for access to the system.
- Security relevant actions associated with periods processing or the changing of security labels or
categories of information.
Fixes:
8/19/2010
VL05
Page 75 of 130
- User ID.
- Type of event.
- Data required to audit the possible use of covert channel mechanisms.
- Privileged activities and other system-level access.
- Starting and ending time for access to the system.
- Security relevant actions associated with periods processing or the changing of security labels or
categories of information.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
V0015647
DG0146
4
Active
DBMS connection block audit
Audit records should include the reason for blacklisting or disabling DBMS connections or accounts.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
DG0146-ORACLE11
Category II
Records of any disabling or locking of account actions taken by the DBMS can contain information
valuable to decisions to employ additional responsive actions.
Audit records do not include the reason for blacklisting or disabling DBMS connections or accounts.
No
8/19/2010
VL05
Page 76 of 130

ECAR-2, ECAR-3
Checks:
Review audit settings for disabling or locking account events based on event failures.
If the settings are not configured to include the cause of the lock or disabling, this is a Finding.
Fixes:
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
Determine and implement audit settings that will collect and store the cause of any DBMS account
or connection lock or disabling actions taken by the DBMS.
V0015149
DG0153
7
Active
DBMS DBA roles assignment approval
DBA roles assignments should be assigned and authorized by the IAO.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DG0153-ORACLE11
Category III
The DBA role and associated privileges provide complete control over the DBMS operation and
integrity. DBA role assignment without authorization could lead to the assignment of these
privileges to untrusted and untrustworthy persons and complete compromise of DBMS integrity.
Default
Finding
DBA roles assignments are not assigned and authorized by the IAO.
Details:
Documentable: No
Documentable
Explanation:
Responsibility: Information Assurance Officer
References:
8/19/2010
VL05
Page 77 of 130

DCSD-1
Checks:
Review the documented procedures for approval and granting of DBA privileges.
Review implementation evidence for the procedures.
If procedures do not exist or evidence that they are followed does not exist, this is a Finding.
Fixes:
Develop, document and implement procedures to ensure all DBA role assignments are authorized
and assigned by the IAO.
Include methods that provide evidence of approval in the procedures.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015654
DG0165
8
Active
DBMS symmetric key management
DBMS symmetric keys should be protected in accordance with NSA or NIST-approved key
management technology or processes.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DG0165-ORACLE11
Category II
Symmetric keys used for encryption protect data from unauthorized access. However, if not
protected in accordance with acceptable standards, the keys themselves may be compromised
and used for unauthorized data access.
Default
DBMS symmetric keys are not protected in accordance with NSA or NIST-approved key
Finding
management technology or processes.
Details:
Documentable: No
Documentable
Explanation:
8/19/2010
VL05
Page 78 of 130

References:
IAKM-1, IAKM-2, IAKM-3
Checks:
If Symmetric keys are present and Oracle Advanced Security is not installed and operational on
the DBMS host, this is a Finding.
If the symmetric key management procedures and configuration settings for the DBMS are not
specified in the System Security Plan, this is a Finding.
If the procedures are not followed with evidence for audit, this is a Finding.
NOTE: This check does not include a review of the key management procedures for validity.
Specific key management requirements may be covered under separate checks.
Fixes:
Symmetric and other encryption keys require the following:
- protection from unauthorized access in transit and in storage
- utilization of accepted algorithms
- generation in accordance with required standards for the key's use
- expiration date
- continuity - key backup and recovery
- key change
- archival key storage (as necessary)
Details for key management requirements are provided by FIPS 140-2 key management
standards available from NIST.
Oracle Advanced Security is required to provide symmetric key management features.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015142
DG0166
9
Active
Protection of DBMS asymmetric encryption keys
Asymmetric keys should use DoD PKI Certificates and be protected in accordance with NIST
(unclassified data) or NSA (classified data) approved key management and processes.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
8/19/2010
VL05
Page 79 of 130
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0166-ORACLE11
Category II
Encryption is only effective if the encryption method is robust and the keys used to provide the
encryption are not easily discovered. Without effective encryption, sensitive data is vulnerable to
unauthorized access.
Asymmetric keys do not use DoD PKI Certificates or are not protected in accordance with NIST
(unclassified data) or NSA (classified data) approved key management and processes.
No
Department of Defense (DOD) Instruction 8500.2, Information Assurance (IA) Implementation IAKM1, IAKM-2, IAKM-3
If Asymmetric keys are present and Oracle Advanced Security is not installed and operational on
the DBMS host, this is a Finding.
For each asymmetric key identified as being used to encrypt sensitive data, verify the key owner
is an application object owner or other non-DBA account.
If the key owner listed is a DBA, this is a Finding.
If any key owner is not the application object owner account or an account specific to the
application as documented in the System Security Plan, this is a Finding.
If any asymmetric keys whose private key is not encrypted exist in the database, this is a Finding.
Review the access permissions to asymmetric keys.
Verify that any permission granted is authorized in the System Security Plan for access to the key.
Examine evidence that an audit record is created whenever the asymmetric key is accessed by
other than authorized users. In particular, view evidence that access by a DBA or other system
privileged account results in the generation of an audit record.
This is required because system privileges that allow access to encryption keys may be used to
access sensitive data where the privileged user does not have a job function need-to-know the
data.
If an audit record is not generated for unauthorized access to the asymmetric key, this is a Finding.
Fixes:
Use DoD code-signing certificates to create asymmetric keys stored in the database that are used
to encrypt sensitive data stored in the database.
Assign the application object owner account as the owner of asymmetric keys used by the
application.
Create audit events for access to the key by other than the application owner account or approved
application objects.
8/19/2010
VL05
Page 80 of 130
Revoke any privileges assigned to the asymmetric key to other than the application object owner
account and authorized users.
Protect the private key by encrypting it with the database system master key where available.
Where available, store encryption keys and certificates on hardware security modules (HSM).
Oracle Advanced Security is required to provide asymmetric key management features.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015657
DG0172
7
Active
DBMS classification level audit
Changes to DBMS security labels should be audited.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DG0172-ORACLE11
Category II
Some DBMS systems provide the feature to assign security labels to data elements. The
confidentiality and integrity of the data depends upon the security label assignment where this
feature is in use. Changes to security label assignment may indicate suspicious activity.
Changes to DBMS security labels are not audited.
No
ECLC-1
8/19/2010
VL05
Page 81 of 130
If no data is identified as being sensitive or classified by the Information Owner, in the System
Security Plan or in the AIS Functional Architecture documentation, this check is Not a Finding.
If no identified sensitive or classified data requires encryption by the Information Owner in the
System Security Plan and/or AIS Functional Architecture documentation, this check is Not a
Finding.
From SQL*Plus:
select * from dba_sa_audit_options;
If no records are returned or if output from the SQL statement above does not show classification
labels being audited as required in the System Security Plan, this is a Finding.
Fixes:
Define the policy for auditing changes to security labels defined for the data.
Document the audit requirements in the System Security Plan and configure database auditing in
accordance with the policy.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
V0015154
DG0190
6
Active
DBMS remote system credential use and access
Credentials stored and used by the DBMS to access remote databases or applications should be
authorized and restricted to authorized users.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
DG0190-ORACLE11
Category II
Credentials defined for access to remote databases or applications may provide unauthorized
access to additional databases and applications to unauthorized or malicious users.
Credentials stored and used by the DBMS to access remote databases or applications are not
authorized or restricted to authorized users.
No
8/19/2010
VL05
Page 82 of 130
Documentable
Explanation:
References:
DCFA-1
Checks:
Review the list of defined database links generated from the DBMS.
Compare to the list in the System Security Plan with the DBA.
If no database links are listed in the database and in the System Security Plan, this check is Not a
Finding.
If any database links are defined in the DBMS, verify the authorization for the definition in the
If any database links exist that are not authorized or not listed in the System Security Plan, this is
a Finding.
Fixes:
Grant access to database links to authorized users or applications only.
Document all database links access authorizations in the System Security Plan.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0015660
DG0192
4
Active
DBMS fully-qualified name for remote access
Remote database or other external access should use fully-qualified names.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
DG0192-ORACLE11
Category II
Severity
Override
8/19/2010
VL05
Page 83 of 130
Guidance:
Vulnerability
Discussion:
The Oracle GLOBAL_NAMES parameter is used to set the requirement for database link names
to be the same name as the remote database whose connection they define. By using the same
name for both, ambiguity is avoided and unauthorized or unintended connections to remote
databases are less likely.
Default Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Remote database or other external access do not use fully-qualified names.

No
DCFA-1
From SQL*Plus:
select value from v$parameter where name = 'global_names';
If the value returned is FALSE, this is a Finding.
Fixes:
From SQL*Plus:
alter system set global_names = TRUE scope = spfile;
NOTE: This parameter, if changed, will affect all currently defined Oracle database links.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0002511
DO0140
7
Active
Oracle default account access
Access to the Oracle SYS and SYSTEM accounts should be restricted to authorized DBAs.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
8/19/2010
VL05
Page 84 of 130
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DO0140-ORACLE11
Category II
The Oracle SYS account has all database privileges assigned to it (SYSDBA). This account is used
to manage the database availability status (startup and shutdown). The SYS account is used by any
DBMS account that connects to the database with SYSDBA privileges. Direct use of the SYS
account does not provide a level of individual accountability for actions taken during its use and
does not provide individual accountability. To preserve accountability, direct access to the SYS
account should be logged manually and its use monitored closely.
Default
Finding
Access to the Oracle SYS and SYSTEM accounts is not restricted to authorized DBAs.
Details:
Documentable: No
Documentable
Explanation:
References:
IAGA-1
Checks:
DB-DO0140-ORACLE11 (Interview)
Review the policy and procedures for use of the Oracle default accounts including direct use of
the Oracle SYS and SYSTEM accounts with the IAO and DBA.
If a policy does not exist for their use, this is a Finding.
If procedures, automated or manual, for logging default account use are not defined or
implemented, this is a Finding.
If monitoring use of default accounts do not exist or is not implemented, this is a Finding.
Fixes:
DB-DO0140-ORACLE11 (Manual)
Design, document and implement policy and procedures for use, logging and monitoring of Oracle
default accounts in the System Security Plan.
Ensure those granted access to the accounts are aware of the accounts and the policies and
procedures for them.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0003846
DO0155
9
Active
Oracle default tablespace assignment
Only authorized system accounts should have the SYSTEM tablespace specified as the default
tablespace.
Comments:
Not a Finding
8/19/2010
VL05
Page 85 of 130
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO0155-ORACLE11
Category II
The Oracle SYSTEM tablespace is used by the database to store all DBMS system objects. Other
use of the system tablespace may compromise system availability and the effectiveness of host
system access controls to the tablespace files.
Unauthorized accounts have the SYSTEM tablespace specified as the default tablespace.
No
DCPA-1
DB-DO0155-ORACLE11 (Script)
From SQL*Plus:
select username from dba_users
where (default_tablespace = 'SYSTEM' or temporary_tablespace = 'SYSTEM')
and username not in
('AURORA$JIS$UTILITY$','AURORA$ORB$UNAUTHENTICATED', 'DBSNMP','MDSYS','ORDPL
UGINS','ORDSYS','OSE$HTTP$ADMIN', 'OUTLN','REPADMIN','SYS','SYSTEM','TRACESVR','MT
SSYS','DIP');
If any non-default account records are returned, this is a Finding.
Fixes:
Create and dedicate tablespaces to support only one application.
Do not share tablespaces between applications.
Do not grant quotas to application object owners on tablespaces not dedicated to their associated
application.
From SQL*Plus:
alter user [username] default tablespace [tablespace_name] temporary tablespace TEMP;
8/19/2010
VL05
Page 86 of 130
Replace [username] with the named user account.

Replace [tablespace_name] with the new default tablespace name.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0003847
DO0157
8
Active
Oracle storage use privileges
Database application user accounts should be denied storage usage for object creation within the
database.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO0157-ORACLE11
Category III
Tablespace storage quotas allow limits on storage use to be assigned to Oracle database users.
Although this does not grant the user the privilege to create objects within the database, it
provides an additional method to restrict unauthorized object creation and ownership.
Database application user accounts have not been denied storage usage for object creation within
the database.
Yes
Review the list of accounts and tablespaces as generated. Confirm accounts assigned tablespace
quotas are documented, authorized and accept as Documentable in VMS.
ECLP-1
From SQL*Plus:
select username, tablespace_name from dba_ts_quotas
where username not in (select distinct owner from dba_objects)
8/19/2010
VL05
Page 87 of 130
and username not in

(select grantee from dba_role_privs where granted_role='DBA');
Review the list of user names returned.
If any belong to application users or application administrators, this is a Finding.
Fixes:
Assign tablespace quotas only to database accounts authorized to create and or own objects in
the database.
Document authorized tablespace quotas for all accounts authorized to own objects in the System
Security Plan.
Remove any quotas assigned to application users, application administrators, or any other
unauthorized accounts.
From SQL*Plus:
alter user [username] quota 0 on [tablespace name];
Replace [username] with the named user and [tablespace name] with the identified tablespace
name.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
V0002515
DO0190
8
Active
Oracle audit table ownership
The audit table should be owned by SYS or SYSTEM.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
MAC /
Confidentiality
Grid:
All Policies
Classified
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DO0190-ORACLE11
Category II
Audit data is frequently targeted by malicious users as it can provide a means to detect their
activity. The protection of the audit trail data is of special concern and requires restrictions to
allow only the auditor and DBMS backup, recovery, and maintenance users access to it.
Default Finding
8/19/2010
VL05
Page 88 of 130
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
The audit table is not owned by SYS or SYSTEM.

No
Checks:
From SQL*Plus:
Chairman of the Joint Chiefs of Staff Manual (CJCSM) 6510.01, Defense-in-Depth:
Information Assuran App. A, Enclosure A, Para.5.b (8)
ECTP-1
select owner from dba_tables where table_name = 'AUD$';

If the owner account returned is not SYS or SYSTEM, this is a Finding.
If the AUD$ tables does not exist, this is a Finding.
Fixes:
Change the owner of the $AUD table to SYS or SYSTEM account.
OR
Recreate the audit table while logged in as SYS or SYSTEM.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0002516
DO0210
7
Active
Oracle shared replication account access
Access to default accounts used to support replication should be restricted to authorized DBAs.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
DO0210-ORACLE11
Category II
8/19/2010
VL05
Vulnerability
Discussion:
Page 89 of 130
Replication database accounts are used for database connections between databases. Replication
requires the configuration of these accounts using the same username and password on all
databases participating in the replication. Replication connections use fixed user database links.
This means that access to the replication account on one server provides access to the other
servers participating in the replication. Granting unauthorized access to the replication account
provides unauthorized and privileged access to all databases participating in the replication group.
Default
Finding
Access to default accounts used to support replication are not restricted to authorized DBAs.
Details:
Documentable: No
Documentable
Explanation:
References:
Department of Defense (DOD) Instruction 8500.2, Information Assurance (IA) Implementation IAGA1
Checks:
From SQL*Plus:
select 'The number of replication objects defined is: '||
count(*) from all_tables
where table_name like 'REPCAT%';
If the count returned is 0, then Oracle Replication is not installed and this check is Not a Finding.
Otherwise:
From SQL*Plus:
select count(*) from sys.dba_repcatlog;
If the count returned is 0, then Oracle Replication is not in use and this check is Not a Finding.
If any results are returned, ask the IAO or DBA if the replication account (the default is
REPADMIN, but may be customized) is restricted to IAO-authorized personnel only.
If it is not, this is a Finding.
If there are multiple replication accounts, confirm that all are justified and documented with the
IAO.
If they are not, this is a Finding.
Fixes:
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Change the password for default and custom replication accounts and provide the password to
IAO-authorized users only.
V0002517
DO0220
8
Active
Oracle instance names
Oracle instance names should not contain Oracle version numbers.
8/19/2010
VL05
Open
Page 90 of 130
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO0220-ORACLE11
Category II
Service names may be discovered by unauthenticated users. If the service name includes version
numbers or other database product information, a malicious user may use that information to
develop a targeted attack.
Oracle instance names contain Oracle version numbers.
No
ECAN-1
From SQL*Plus:
select instance_name from v$instance;
select version from v$instance;
If the instance name returned references the Oracle release number, this is a Finding.
Numbers used that include version numbers by coincidence are not a Finding.
The DBA should be able to relate the significance of the presence of a digit in the SID.
Fixes:
Follow the instructions in Oracle MetaLink Note 15390.1 (and related documents) to change the
SID for the database without re-creating the database to a value that does not identify the Oracle
version.
8/19/2010
VL05
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
Page 91 of 130
DO0221
7
Active
Oracle default SID name
The Oracle SID should not be the default SID.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO0221-ORACLE11
Category III
Use of the default Oracle System Identifier (SID) leaves the database vulnerable to attacks that
target Oracle installations running under default SID. Using a custom name helps protect the
database against this kind of targeted attack.
The Oracle SID is the default SID.
No
ECAN-1
From SQL*Plus:
select instance_name from v$instance;
Review the instance name with the DBA.
Ask the DBA if the instance name was chosen by the installer to conform to local naming
conventions, etc. or if it was determined by the installation software.
If it was named by the installation software, this is a Finding.
Fixes:
Follow the instructions in Oracle MetaLink Note 15390.1 (and related documents) to change the
SID for the database without re-creating the database to a value other than the application default.
8/19/2010
VL05
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Page 92 of 130
V0003849
DO0231
6
Active
Oracle application object owner tablespaces
Application owner accounts should have a dedicated application tablespace.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO0231-ORACLE11
Category II
Separation of tablespaces by application helps to protect the application from resource contention
and unauthorized access that could result from storage space reuses or host system access
controls. Application data should be stored separately from system and custom user-defined
objects to facilitate administration and management of its data storage. The SYSTEM tablespace
should never be used for application data storage in order to prevent resource contention and
performance degradation.
Application owner accounts do not have a dedicated application tablespace.
Yes
Review the list of accounts and tablespaces as generated. Confirm accounts are documented,
authorized and accept as Documentable in VMS.
DCPA-1
select distinct owner, tablespace_name
from dba_tables
where owner not in
('SYS','SYSTEM','OUTLN','OLAPSYS','CTXSYS','WKSYS','ODM',
8/19/2010
VL05
Page 93 of 130
'ODM_MTR','MDSYS','ORDSYS','WMSYS','RMAN','XDB')
and tablespace_name is not NULL
and (owner, table_name) not in
(select owner, table_name from dba_external_tables)
order by tablespace_name;
Review the list of returned table owners with the tablespace used.
If any of the owners listed are not default Oracle accounts and use the SYSTEM or any other
tablespace not dedicated for the applications use, this is a Finding.
Look for multiple applications that may share a tablespace.
If no records were returned, ask the DBA if any applications use this database.
If no applications use the database, this is not a Finding.
If there are applications that do use the database or if the application uses the SYS or other
default account and SYSTEM tablespace to store its objects, this is a Finding.
Fixes:
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
Create and assign dedicated tablespaces for the storage of data by each application using the
CREATE TABLESPACE command.
V0015747
DO0233
5
Active
Oracle DIAGNOSTIC_DEST parameter
The directory assigned to the DIAGNOSTIC_DEST parameter should be protected from
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DO0233-ORACLE11
Category II
The DIAGNOSTIC_DEST is used to indicate the directory where trace, alert, core and incident
directories and files are located. The files may contain sensitive data or information that could prove
useful to potential attackers.
8/19/2010
VL05
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Page 94 of 130
The directory assigned to the DIAGNOSTIC_DEST parameter is not protected from unauthorized
access.
No
DCPA-1
From SQL*Plus:
select value from v$parameter where name='diagnostic_dest';
On UNIX Systems:
ls -ld [pathname]
Substitute [pathname] with the directory path listed from the above SQL command.
If any account other than the Oracle process and software owner accounts, Administrators, DBAs,
System group or developers authorized to write and debug applications on this database are
listed, this is a Finding.
Fixes:
Alter host system permissions to the DIAGNOSTIC_DEST directory to the Oracle process and
software owner accounts, DBAs, SAs (if required) and developers or other users that may
specifically require access for debugging or other purposes.
Authorize and document user access requirements to the directory outside of the Oracle, DBA
and SA account list.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
V0003850
DO0234
7
Active
Oracle AUDIT_FILE_DEST parameter
The directory assigned to the AUDIT_FILE_DEST parameter should be protected from unauthorized
access.
Comments:
8/19/2010
VL05
Page 95 of 130
Open
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO0234-ORACLE11
Category II
The AUDIT_FILE_DEST parameter specifies the directory where the database audit trail file is
stored (when AUDIT_TRAIL parameter is set to OS, xml or xml, extended where supported by
the DBMS). Unauthorized access or loss of integrity of the audit trail could result in loss of
accountability or the ability to detect suspicious activity. This directory also contains the audit trail of
the SYS and SYSTEM accounts that captures privileged database events when the database is not
running (when AUDIT_SYS_OPERATIONS parameter is set to TRUE).
The directory assigned to the AUDIT_FILE_DEST parameter is not protected from unauthorized
access.
No
ECTP-1
From SQL*Plus:
select value from v$parameter where name = 'audit_trail';
select value from v$parameter where name = 'audit_file_dest';
If audit_trail is NOT set to TRUE, OS, XML or XML, EXTENDED per MetaLink Note 30690.1, this
check is Not a Finding.
On UNIX Systems:
ls -ld [pathname]
Substitute [pathname] with the directory path listed from the above SQL command for
audit_file_dest.
8/19/2010
VL05
Page 96 of 130

Browse to the directory specified. Select and right-click on the directory, select Properties, select
the Security tab. On Windows hosts, records are also written to the Windows application event
log. The location of the application event log is listed under Properties for the log under the
Windows console. The default location is C:\WINDOWS\system32
\config\EventLogs\AppEvent.Evt.
If permissions are granted to everyone, this is a Finding. If any accounts other than the
Administrators, DBAs, System group, auditors or backup operators are listed, this is a Finding.
Fixes:
Alter host system permissions to the AUDIT_FILE_DEST directory to the Oracle process and
software owner accounts, DBAs, backup accounts, SAs (if required) and auditors.
Authorize and document user access requirements to the directory outside of the Oracle, DBA
and SA account list in the System Security Plan.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0003854
DO0238
7
Active
Oracle LOG_ARCHIVE_DEST parameter
The directories assigned to the LOG_ARCHIVE_DEST* parameters should be protected from
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DO0238-ORACLE11
Category II
The LOG_ARCHIVE_DEST parameter is used to specify the directory to which Oracle archive logs
are written. Where the DBMS availability and recovery to a specific point in time is critical, the
protection of archive log files is critical. Archive log files may also contain unencrypted sensitive
data. If written to an inadequately protected or invalidated directory, the archive log files may be
accessed by unauthorized persons or processes.
Default
The directories assigned to the LOG_ARCHIVE_DEST* parameters are not protected from
Finding
Details:
Documentable: No
8/19/2010
VL05
Page 97 of 130
Documentable
Explanation:
References:
DCPA-1
Checks:
From SQL*Plus:
select log_mode from v$database;
select value from v$parameter where name = 'log_archive_dest';
select value from v$parameter where name = 'log_archive_duplex_dest';
select name, value from v$parameter where name LIKE 'log_archive_dest_%';
If the value returned for LOG_MODE is NOARCHIVELOG, this check is Not a Finding.
If a value is not returned for LOG_ARCHIVE_DEST and no values are returned for any of the
LOG_ARCHIVE_DEST_[1-10] parameters, this is a Finding.
NOTE: LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST are incompatible with the
LOG_ARCHIVE_DEST_n parameters, and must be defined as the null string (' ') when any
LOG_ARCHIVE_DEST_n parameter has a value other than a null string.
On UNIX Systems:
ls -ld [pathname]
Substitute [pathname] with the directory paths listed from the above SQL statements for
log_archive_dest and log_archive_duplex_dest.
If any account other than the Oracle process and software owner accounts, Administrators, DBAs,
System group or developers authorized to write and debug applications on this database are
listed, this is a Finding.
Fixes:
Specify a valid and protected directory for archive log files.
Restrict access to the Oracle process and software owner accounts, DBAs, and backup operator
accounts.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
V0002519
DO0240
8
Active
Oracle OS_ROLES parameter
8/19/2010
VL05
Page 98 of 130
Long Name:
The Oracle OS_ROLES parameter should be set to FALSE.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DO0240-ORACLE11
Category III
The OS_ROLES parameter specifies whether Oracle roles are defined and managed by the
DBMS or by the host operating system. To maintain and support the separation of duties
between host system administration and DBMS administration, the DBMS must be configured to
use only roles defined and managed by the DBA. Separation of duties supports assignment of
privileges by job function and supports accountability.
Default Finding
The Oracle OS_ROLES parameter is not set to FALSE.
Details:
Documentable: No
Documentable
Explanation:
References:
DCSD-1
Checks:
From SQL*Plus:
select value from v$parameter where name = 'os_roles';
If the value returned is not FALSE, this is a Finding.
Fixes:
From SQL*Plus:
alter system set os_roles = FALSE scope = spfile;
8/19/2010
VL05
Page 99 of 130
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
V0003857
DO0243
7
Active
Oracle _TRACE_FILES_PUBLIC parameter
The Oracle _TRACE_FILES_PUBLIC parameter if present should be set to FALSE.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
MAC /
Confidentiality
Grid:
All Policies
Classified
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO0243-ORACLE11
Category II
The _TRACE_FILES_PUBLIC parameter is used to make trace files used for debugging
database applications and events available to all database users. Use of this capability
precludes the discrete assignment of privileges based on job function. Additionally, its use may
provide access to external files and data to unauthorized users.
The Oracle _TRACE_FILES_PUBLIC parameter is present and not set to FALSE.
No
ECAN-1
From SQL*Plus:
select value from v$parameter where name = '_trace_files_public';
If the value returned is TRUE, this is a Finding.
If the parameter does not exist or is set to FALSE, this is Not a Finding.
Fixes:
From SQL*Plus (shutdown database instance):
shutdown immediate
8/19/2010
VL05
Page 100 of 130
From SQL*Plus (create a pfile from spfile):

create pfile='[PATH]init[SID].ora' from spfile;
Edit the init[SID].ora file and remove the following line:
*._trace_files_public=TRUE
From SQL*Plus (update the spfile using the pfile):
create spfile from pfile='[PATH]init[SID].ora';
From SQL*Plus (start the database instance):
startup
NOTE: [PATH] depends on the platform (Windows or UNIX).
Ensure the file is directed to a writable location.
[SID] is equal to the oracle SID or database instance ID.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0002520
DO0250
8
Active
Oracle database link usage
Fixed user and public database links should be authorized for use.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DO0250-ORACLE11
Category II
Database links define connections that may be used by the local database to access remote
Oracle databases. These links provide a means for a compromise to the local database to spread
to remote databases in the distributed database environment. Limiting or eliminating use of
database links where they are not required to support the operational system can help isolate
compromises to the local or a limited number of databases.
Default
8/19/2010
VL05
Page 101 of 130
Finding
Details:
Documentable:
Documentable
Explanation:
Fixed user and public database links are not authorized for use.
Yes
Review the list of accounts and database links as generated. Confirm database links are
documented, authorized and accept as Documentable in VMS. Confirm database links used for
replication are documented, authorized and accept as Documentable in VMS.
References:
DCFA-1
Checks:
From SQL*Plus:
select owner||': '||db_link from dba_db_links;
select count(*) from sys.dba_repcatlog;
If no records are returned from the first SQL statement, this check is Not a Finding.
If the value of the count returned is 0 for the second SQL statement, none of the database links
listed above, if any, is used for replication.
Confirm the public and fixed user database links listed are documented in the System Security
Plan, are authorized by the IAO and are used for replication or operational system requirements.
If any are not, this is a Finding.
Fixes:
Document all authorized connections from the database to remote databases in the System
Security Plan.
Remove all unauthorized remote database connection definitions from the database.
From SQL*Plus:
drop database link [link name];
OR
drop public database link [link name];
Review remote database connection definitions periodically and confirm their use is still required
and authorized.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0002521
DO0260
7
Active
Oracle control file availability
A minimum of two Oracle control files should be defined and configured to be stored on separate,
archived physical disks or archived partitions on a RAID device.
Comments:
Not a Finding
Not Applicable
8/19/2010
VL05
Page 102 of 130
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO0260-ORACLE11
Category II
Oracle control files are used to store information critical to Oracle database integrity. Oracle uses
these files to maintain time synchronization of database files as well as at system startup to verify
the validity of system data and log files. Loss of access to the control files can affect database
availability, integrity and recovery.
A minimum of two Oracle control files are not defined and configured to be stored on separate,
archived physical disks or archived directories on a RAID device.
No
COBR-1
From SQL*Plus:
select name from v$controlfile;
DoD guidance recommends:
1. A minimum of two distinct control files for each Oracle Database Instance.
2a. Each control file is to be located on separate, archived physical storage devices
OR
2b. Each control file is to be located on separate, archived directories within one or more RAID
devices
3. The Logical Paths for each control file should differ at the highest level supported by your
configuration, for example:
UNIX
/ora03/app/oracle/{SID}/control/control01.ctl
/ora04/app/oracle/{SID}/control/control02.ctl
Windows
D:/oracle/{SID}/control/control01.ctl
E:/oracle/{SID}/control/control02.ctl
8/19/2010
VL05
Page 103 of 130
If this minimum listed above is not met, this is a Finding.

Consult with the SA or DBA to determine that the mount points or partitions referenced in the file
paths indicate separate physical disks or directories on RAID devices.
NOTE: Distinct does not equal dedicated. You may share directory space with other Oracle
database instances if present.
Fixes:
To prevent loss of service during disk failure, multiple copies of Oracle control files should be
maintained on separate disks in archived directories or on separate, archived directories within
one or more RAID devices.
Adding or moving a control file requires careful planning and execution.
Please consult and follow the instructions for creating control files in the Oracle Database
Administrator's Guide, under Steps for Creating New Control Files.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0002522
DO0270
7
Active
Oracle redo log file availability
A minimum of two Oracle redo log groups/files should be defined and configured to be stored on
separate, archived physical disks or archived directories on a RAID device.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
DO0270-ORACLE11
Category II
The Oracle redo log files store the detailed information on changes made to the database. This
information is critical to database recovery in case of a database failure.
A minimum of two Oracle redo log groups/files is not defined and configured to be stored on
separate, archived physical disks or archived directories on a RAID device.
No
8/19/2010
VL05
Page 104 of 130

References:
COBR-1
Checks:
From SQL*Plus:
select count(*) from V$LOG;
If the value of the count returned is less than 2, this is a Finding.
From SQL*Plus:
select count(*) from V$LOG where members > 1;
If the value of the count returned is less than 2 and a RAID storage device is not being used, this
is a Finding.
Fixes:
To define additional redo log file groups:
From SQL*Plus (Example):
alter database add logfile group 2
('diska:log2.log' ,
'diskb:log2.log') size 50K;
To add additional redo log file [members] to an existing redo log file group:
From SQL*Plus (Example):
alter database add logfile member 'diskc:log2.log'
to group 2;
Replace diska, diskb, diskc with valid, different disk drive specifications.
Replace log#.log file with valid or custom names for the log files.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0003437
DO0320
7
Active
Oracle PUBLIC role privileges
Application role permissions should not be assigned to the Oracle PUBLIC role.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
8/19/2010
VL05
Page 105 of 130
Policy:
MAC /
Confidentiality
Grid:
All Policies
Classified
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DO0320-ORACLE11
Category II
Application roles have been granted to PUBLIC. Permissions granted to PUBLIC are granted
to all users of the database. Custom roles should be used to assign application permissions to
functional groups of application users. The installation of Oracle does not assign role
permissions to PUBLIC.
Default Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Application role permissions are assigned to the Oracle PUBLIC role.

No
Chairman of the Joint Chiefs of Staff Manual (CJCSM) 6510.01, Defense-in-Depth:
Information Assuran App. A, Enclosure A, Para.5.b (8)
DCFA-1
From SQL*Plus:
select granted_role from dba_role_privs where grantee = 'PUBLIC';
If any roles are listed, this is a Finding.
Fixes:
Revoke role grants from PUBLIC.
Do not assign role privileges to PUBLIC.
From SQL*Plus:
revoke [role name] from PUBLIC;
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0003438
DO0340
6
Active
Oracle application administration roles enablement
Oracle application administration roles should be disabled if not required and authorized.
Comments:
Not a Finding
Not Applicable
8/19/2010
VL05
Page 106 of 130
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO0340-ORACLE11
Category II
Application administration roles, which are assigned system or elevated application object
privileges, should be protected from default activation. Application administration roles are
determined by system privilege assignment (create / alter / drop user) and application user role
ADMIN OPTION privileges.
Oracle application administration roles are enabled and not required or authorized.
Yes
Review the accounts and roles as generated. Confirm the account(s) and role assignments are
DCFA-1
select grantee, granted_role from dba_role_privs
where default_role='YES'
and granted_role in
(select grantee from dba_sys_privs where upper(privilege) like '%USER%')
and grantee not in
('DBA', 'SYS', 'SYSTEM', 'CTXSYS', 'DBA', 'IMP_FULL_DATABASE',
'MDSYS', 'SYS', 'WKSYS')
and grantee not in (select distinct owner from dba_tables)
and grantee not in
(select distinct username from dba_users where upper(account_status) like
'%LOCKED%');
Review the list of accounts reported for this check and ensures that they are authorized
application administration roles.
If any are not authorized application administration roles, this is a Finding.
Fixes:
For each role assignment returned, issue:
From SQL*Plus:
alter user [username] default role all except [role];
8/19/2010
VL05
Page 107 of 130
If the user has more than one application administration role assigned, then you will have to
remove assigned roles from default assignment and assign individually the appropriate default
roles.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0003439
DO0350
7
Active
Oracle system privilege assignment
Oracle system privileges should not be directly assigned to unauthorized accounts.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO0350-ORACLE11
Category II
System privileges allow system-wide changes to the database or database objects. Unauthorized
use of system privileges may jeopardize production applications, application data, or the database
configuration and operation.
Oracle system privileges are directly assigned to unauthorized accounts.
Yes
ECLP-1, ECLP-2
select grantee||': '||PRIVILEGE from dba_sys_privs
where privilege<>'CREATE SESSION'
8/19/2010
VL05
Page 108 of 130
and grantee not in

('PUBLIC', 'AQ_ADMINISTRATOR_ROLE', 'AQ_USER_ROLE', 'CTXSYS',
'DBA', 'DELETE_CATALOG_ROLE', 'EXECUTE_CATALOG_ROLE',
'EXP_FULL_DATABASE', 'GATHER_SYSTEM_STATISTICS',
'HS_ADMIN_ROLE', 'IMP_FULL_DATABASE',
'LOGSTDBY_ADMINISTRATOR', 'MDSYS', 'ODM', 'OEM_MONITOR',
'OLAPSYS', 'ORDSYS', 'OUTLN', 'MTSSYS',
'RECOVERY_CATALOG_OWNER', 'SELECT_CATALOG_ROLE',
'SNMPAGENT', 'SYSTEM', 'WKSYS', 'WKUSER', 'WMSYS',
'WM_ADMIN_ROLE', 'XDB', 'ANONYMOUS', 'CONNECT', 'DBSNMP',
'JAVADEBUGPRIV', 'ODM_MTR', 'OLAP_DBA', 'ORDPLUGINS',
'RESOURCE', 'RMAN', 'SYS', 'WKPROXY', 'AURORA$JIS$UTILITY$',
'AURORA$ORB$UNAUTHENTICATED', 'OSE$HTTP$ADMIN',
'TIMESERIES_DBA', 'TIMESERIES_DEVELOPER', 'OLAP_USER')
and grantee not in
and grantee not in
(select username from dba_users where upper(account_status) like
'%LOCKED%');
If any records are returned, perform the following instructions for this check to determine the
finding status.
Review the list of active non-DBA accounts and roles granted system privileges.
Any accounts listed as authorized for checks DO0340 (Oracle application administration roles
enablement) and DG0008 (Oracle object ownership) are not a Finding.
On a production database, confirm that any accounts listed with create user, alter user, drop user
belong to authorized application administration roles.
On a development system, ensure that system privileges assigned to developers are justified and
authorized by the IAO.
If any unauthorized, unjustified or undocumented application user roles or accounts are listed, this
is a Finding.
Fixes:
Document and justify system privileges assigned to users/roles in the System Security Plan and
authorize with the IAO.
Remove unauthorized or unjustified system privileges from user accounts or roles.
From SQL*Plus:
revoke [privilege] from [user or role name];
Replace [privilege] with the named privilege and [user or role name] with the identified user or role.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0003865
DO0420
9
Active
Oracle XML DB
The XDB Protocol server should be uninstalled if not required and authorized for use.
Comments:
Not a Finding
8/19/2010
VL05
Page 109 of 130
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO0420-ORACLE11
Category III
The XML DB supports storage and retrieval of XML data objects in the Oracle Database. It
requires the configuration of an Oracle shared-server dispatcher that is activated / used by the
Oracle listener to pass http XML requests. If this service is not required, it should be uninstalled.
The XDB Protocol server is installed and not required and authorized for use.
No
DCFA-1
From SQL*Plus:
select count(*) from dba_users where username = 'XDB';
select count(*) from v$parameter where name = 'dispatchers'
and value like '%XDB%';
If a value of 0 is returned for either the first or the second SQL statement above, this is not a
Finding.
If a value of 1 (or more) is returned for the second SQL statement, review the System Security
Plan to verify existence of all XML DB dispatchers is authorized.
If it is not, this is a Finding.
Fixes:
If the database is authorized to support web services using XML over HTTP, then include
documentation and authorization in the System Security Plan.
If not authorized, uninstall XML DB per Oracle MetaLink Note 742014.1.
8/19/2010
VL05
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Page 110 of 130
V0002527
DO3440
7
Active
Oracle DBA role assignment
The DBA role should not be granted to unauthorized user accounts.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO3440-ORACLE11
Category II
The DBA role is very powerful and access to it should be restricted. Verify that any database
account granted the DBA role is explicitly authorized by the IAO. In addition to full access to
database objects, access to the DBA role by unauthorized accounts may provide full access to the
server. Verify that individual DBA accounts are created for each DBA and that the DBA accounts
are used only for DBA functions.
The DBA role has been granted to unauthorized user accounts.
Yes
Review the accounts as generated. Confirm the account(s) and role assignments are documented,
authorized and accept as Documentable in VMS.
ECLP-1
select grantee from dba_role_privs
where granted_role='DBA'
and grantee not in
('SYS', 'SYSTEM', 'SYSMAN', 'CTXSYS', 'WKSYS');
If any accounts are listed, review against the list of DBA accounts authorized by the IAO in the
8/19/2010
VL05
Page 111 of 130
If any accounts are assigned the DBA role and are not authorized by the IAO, this is a Finding.
If any DBA roles are assigned to developer accounts and this is a production database, this is a
Finding.
If any DBA roles are assigned to shared accounts, this is a Finding.
Fixes:
Authorize and document all DBA role authorizations in the System Security Plan.
Revoke DBA role membership from unauthorized accounts.
Revoke DBA role membership from any accounts assigned to a developer job function on a
shared production / development database.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
V0002531
DO3447
8
Active
Oracle OS_AUTHENT_PREFIX parameter
The Oracle OS_AUTHENT_PREFIX parameter should be changed from the default value of OPS$.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DO3447-ORACLE11
Category III
The OS_AUTHENT_PREFIX parameter defines the prefix for database account names to be
identified EXTERNALLY by the operating system. When set to the special value of OPS$,
accounts defined with the prefix of OPS$ may authenticate either with a password or with OS
authentication. Use of more than one authentication method to access a single account results
in a loss of accountability, that is, it is similar to a shared account. Setting this parameter to a
value other than OPS$ prevents a shared usage of a single account.
Default Finding
The Oracle OS_AUTHENT_PREFIX parameter is set to the default value of OPS$.
Details:
Documentable: No
Documentable
Explanation:
8/19/2010
VL05
Page 112 of 130
References:
Checks:

IAGA-1
From SQL*Plus:
select value from v$parameter where name = 'os_authent_prefix';
If the value returned is OPS$ or ops$, this is a Finding.
Fixes:
Specify an operating system authenticated username prefix other than OPS$.
From SQL*Plus:
alter system set os_authent_prefix = [prefix value] scope = spfile;
Compliant selections for [prefix value] are:
a null string ('')
a text value other than 'OPS$'
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0002533
DO3451
8
Active
WITH GRANT OPTION privileges
The Oracle WITH GRANT OPTION privilege should not be granted to non-DBA or non-Application
administrator user accounts.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
DO3451-ORACLE11
Category II
Severity
Override
8/19/2010
VL05
Page 113 of 130
Guidance:
Vulnerability
Discussion:
An account permission to grant privileges within the database is an administrative function.

Minimizing the number and privileges of administrative accounts reduces the chances of
privileged account exploitation. Application user accounts should never require WITH GRANT
OPTION privileges since, by definition, they require only privileges to execute procedures or
view / edit data.
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
The Oracle WITH GRANT OPTION privilege has been granted to non-DBA or non-Application
administrator user accounts.
No

ECLP-1
From SQL*Plus:
select grantee||': '||owner||'.'||table_name from dba_tab_privs
where grantable = 'YES'
and owner not in (select distinct owner from dba_objects)
and grantee not in
order by grantee;
If any accounts are listed, this is a Finding.
Fixes:
Revoke privileges granted the WITH GRANT OPTION from non-DBA and accounts that do not
own application objects.
Re-grant privileges without specifying WITH GRANT OPTION.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0002539
DO3475
7
Active
Oracle PUBLIC access to restricted packages
Execute permission should be revoked from PUBLIC for restricted Oracle packages.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
MAC /
All Policies
8/19/2010
VL05
Page 114 of 130
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO3475-ORACLE11
Category II
Access to the following packages should be restricted to authorized accounts only. UTL_FILE:
allows Oracle accounts to read and write files on the host operating system. UTL_SMTP: allows
messages to be sent from an arbitrary user. UTL_TCP: allows arbitrary data to be sent from the
database server. UTL_HTTP: allows the database server to send and receive data via HTTP.
DBMS_RANDOM: allows encrypting of data without requiring safe management of encryption
keys. DBMS_LOB: allows users access to files stored outside the database. DBMS_SQL: allows
users to write dynamic SQL procedures. DBMS_SYS_SQL: allows users to execute SQL with DBA
privileges. DBMS_JOB: allows users to submit jobs to the database job queue.
DBMS_BACKUP_RESTORE: allows users to backup and restore database data.
DBMS_OBFUSCATION_TOOLKIT: allows users access to encryption and decryption functions.
Execute permission has not been revoked from PUBLIC for restricted Oracle packages.
No
ECLP-1
From SQL*Plus:
select table_name from dba_tab_privs
where grantee='PUBLIC'
and privilege ='EXECUTE'
and table_name in
('UTL_FILE', 'UTL_SMTP', 'UTL_TCP', 'UTL_HTTP',
'DBMS_RANDOM', 'DBMS_LOB', 'DBMS_SQL',
'DBMS_SYS_SQL', 'DBMS_JOB',
'DBMS_BACKUP_RESTORE',
'DBMS_OBFUSCATION_TOOLKIT');
Fixes:
Revoking all default installation privilege assignments from PUBLIC is not required at this time.
However, execute permissions to the specified packages is required to be revoked from PUBLIC.
Removal of these privileges from PUBLIC may result in invalid packages in version 10.1 and later
of Oracle and an inability to execute default Oracle applications and utilities. To correct this
problem, grant execute privileges on these packages directly to the SYSMAN, WKSYS, MDSYS
and SYSTEM accounts as well as any other default Oracle database and custom application
object owner accounts as necessary to support execution of applications/utilities installed with an
Oracle Database Server.
At a minimum, revoke the following:
From SQL*Plus:
revoke execute on UTL_FILE from PUBLIC;
8/19/2010
VL05
Page 115 of 130
revoke execute on UTL_SMTP from PUBLIC;

revoke execute on UTL_TCP from PUBLIC;
revoke execute on UTL_HTTP from PUBLIC;
revoke execute on DBMS_RANDOM from PUBLIC;
revoke execute on DBMS_LOB from PUBLIC;
revoke execute on DBMS_SQL from PUBLIC;
revoke execute on DBMS_SYS_SQL from PUBLIC;
revoke execute on DBMS_JOB from PUBLIC;
revoke execute on DBMS_BACKUP_RESTORE from PUBLIC;
revoke execute on DBMS_OBFUSCATION_TOOLKIT from PUBLIC;
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
V0002552
DO3536
7
Active
Oracle IDLE_TIME profile parameter
The IDLE_TIME profile parameter should be set for Oracle profiles IAW DoD policy.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
DO3536-ORACLE11
Category II
The Idle Time Resource Usage setting limits the maximum idle time allowed in a session. Idle time
is a continuous inactive period during a session, expressed in minutes. Long-running queries and
other operations are not subject to this limit. Setting an Idle Time Resource Usage limit helps
prevent users from leaving applications open when they are away from their desks.
The IDLE_TIME profile parameter is not set for Oracle profiles IAW DoD policy.
No
ECLO-1
8/19/2010
VL05
Page 116 of 130

Checks:
From SQL*Plus:
select profile, limit from DBA_PROFILES
where profile = DEFAULT
and resource_name = IDLE_TIME;
select profile, limit from DBA_PROFILES
where profile <> DEFAULT
and resource_name = IDLE_TIME;
If the idle time on the DEFAULT profile is greater than 15 minutes, this is a Finding.
If any non-default profiles have an idle time setting greater than 60 minutes or are set to an
UNLIMITED value and not documented in the System Security Plan or not authorized by the IAO,
this is a Finding.
Fixes:
Modify profiles to meet the idle time requirement.
From SQL*Plus:
alter profile default limit idle_time 15;
alter profile [profile name] limit idle_time [IAO-approved value];
Authorize and document any profiles that require idle times greater than 15 minutes in the System
Security Plan.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0002554
DO3538
8
Active
Oracle REMOTE_OS_AUTHENT parameter
The Oracle REMOTE_OS_AUTHENT parameter should be set to FALSE.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
DO3538-ORACLE11
Category I
This finding may be downgraded to a Category II severity code if the following mitigations have
been implemented: 1) A logon trigger verifies that any connections to accounts identified
8/19/2010
VL05
Page 117 of 130
externally come from a single, specific IP address and kills the connection if determined
otherwise, and 2) To help prevent access by a spoofed IP address, the single connecting system
and the database host are isolated behind a firewall with either Network Address Translation
(NAT) implemented and/or the firewall is configured to reject connections from the single source
IP address originating outside the isolated segment.
Setting this value to TRUE allows operating system authentication over an unsecured
connection. Trusting remote operating systems can allow a user to impersonate another
operating system user and connect to the database without having to supply a password. If
REMOTE_OS_AUTHENT is set to true, the only information a remote user needs to connect to
the database is the name of any user whose account is setup to be authenticated by the
operating system.
Severity
Override
Guidance:
Vulnerability
Discussion:
Default Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
The Oracle REMOTE_OS_AUTHENT parameter is not set to FALSE.

No
IAIA-1, IAIA-2
From SQL*Plus:
select value from v$parameter where name = 'remote_os_authent';
If the value returned does not equal FALSE, this is a Finding.
Fixes:
Document remote OS authentication in the System Security Plan.
If not required or not mitigated to an acceptable level, disable remote OS authentication.
From SQL*Plus:
alter system set remote_os_authent = FALSE scope = spfile;
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0002555
DO3539
8
Active
Oracle REMOTE_OS_ROLES parameter
The Oracle REMOTE_OS_ROLES parameter should be set to FALSE.
Comments:
Not a Finding
Not Applicable
Not Reviewed
8/19/2010
VL05
Condition:
Page 118 of 130
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO3539-ORACLE11
Category I
Setting REMOTE_OS_ROLES to TRUE allows operating system groups to control Oracle roles.
The default value of FALSE causes roles to be identified and managed by the database. If
REMOTE_OS_ROLES is set to TRUE, a remote user could impersonate another operating system
user over a network connection.
The Oracle REMOTE_OS_ROLES parameter is not set to FALSE.
No

ECLP-1
From SQL*Plus:
select value from v$parameter where name = 'remote_os_roles';
If the returned value is not FALSE or not documented in the System Security Plan as required,
this is a Finding.
Fixes:
Document remote OS roles in the System Security Plan.
If not required, disable use of remote OS roles.
From SQL*Plus:
alter system set remote_os_roles = FALSE scope = spfile;
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
V0002556
DO3540
9
Active
Oracle SQL92_SECURITY parameter
The Oracle SQL92_SECURITY parameter should be set to TRUE.
8/19/2010
VL05
Page 119 of 130
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO3540-ORACLE11
Category II
The configuration option SQL92_SECURITY specifies whether table-level SELECT privileges

are required to execute an update or delete that references table column values. If this option is
disabled (set to FALSE), the UPDATE privilege can be used to determine values that should
require SELECT privileges.
The Oracle SQL92_SECURITY parameter is not set to TRUE.
No
DCFA-1
From SQL*Plus:
select value from v$parameter where name = 'sql92_security';
If the value returned is set to FALSE, this is a Finding.
If the parameter is set to TRUE or does not exist, this is Not a Finding.
Fixes:
Enable SQL92 security.
From SQL*Plus:
alter system set sql92_security = TRUE scope = spfile;
8/19/2010
VL05
Page 120 of 130
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
V0002558
DO3546
8
Active
Oracle REMOTE_LOGIN_PASSWORDFILE parameter
The Oracle REMOTE_LOGIN_PASSWORDFILE parameter should be set to EXCLUSIVE or NONE.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO3546-ORACLE11
Category II
The REMOTE_LOGIN_PASSWORDFILE setting of "NONE" disallows remote administration of

the database. The REMOTE_LOGIN_PASSWORDFILE setting of "EXCLUSIVE" allows for
auditing of individual DBA logins to the SYS account. If not set to "EXCLUSIVE", remote
connections to the database as "internal" or "as SYSDBA" are not logged to an individual
account.
The Oracle REMOTE_LOGIN_PASSWORDFILE parameter is not set to EXCLUSIVE or NONE.
No
IAGA-1
From SQL*Plus:
select value from v$parameter where name = 'remote_login_passwordfile';
If the value returned does not equal 'EXCLUSIVE' or 'NONE', this is a Finding.
Fixes:
Disable use of the remote_login_passwordfile where remote administration is not authorized by
specifying a value of NONE.
8/19/2010
VL05
Page 121 of 130
If authorized, restrict use of a password file to exclusive use by each database by specifying a
value of EXCLUSIVE.
From SQL*Plus:
alter system set remote_login_passwordfile = 'EXCLUSIVE' scope = spfile;
OR
alter system set remote_login_passwordfile = 'NONE' scope = spfile;
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0002561
DO3609
7
Active
System privileges granted WITH ADMIN OPTION
System privileges granted using the WITH ADMIN OPTION should not be granted to unauthorized
user accounts.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
DO3609-ORACLE11
Category II
The WITH ADMIN OPTION allows the grantee to grant a privilege to another database account.
Best security practice restricts the privilege of assigning privileges to authorized personnel.
Authorized personnel include DBA's, object owners, and, where designed and included in the
application's functions, application administrators. Restricting privilege-granting functions to
authorized accounts can help decrease mismanagement of privileges and wrongful assignments
to unauthorized accounts.
System privileges granted using the WITH ADMIN OPTION are granted to unauthorized user
accounts.
No
8/19/2010
VL05
Page 122 of 130
References:
ECLP-1
Checks:
From SQL*Plus:
select grantee, privilege from dba_sys_privs
('SYS', 'SYSTEM', 'AQ_ADMINISTRATOR_ROLE', 'DBA',
'MDSYS', 'LBACSYS', 'SCHEDULER_ADMIN',
'WMSYS')
and admin_option = 'YES'
and grantee not in
(select grantee from dba_role_privs where granted_role = 'DBA');
If any accounts are listed, this is a Finding.
Fixes:
Revoke assignment of privileges with the WITH ADMIN OPTION from unauthorized users and regrant them without the option.
From SQL*Plus:
revoke [privilege name] from user [username];
Replace [privilege name] with the named privilege and [username] with the named user.
Restrict use of the WITH ADMIN OPTION to authorized administrators.
Document authorized privilege assignments with the WITH ADMIN OPTION in the System
Security Plan.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0002562
DO3610
6
Active
Oracle minimum object auditing
Required object auditing should be configured.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
8/19/2010
VL05
Page 123 of 130
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO3610-ORACLE11
Category II
Database object definitions and configurations require similar oversight as application libraries to
detect unauthorized changes. Unauthorized changes may indicate attempts to compromise data or
application object integrity or confidentiality. Any access to audit data objects stored in the
database must be audited to detect any attempts to compromise the audit trail. A compromise to
audit data could jeopardize accountability for unauthorized actions.
Required object auditing is not configured.
No
ECAR-1
From SQL*Plus:
select count(*) from all_def_audit_opts where ren = 'A/A';
If the count of 0 is returned, this is a Finding.
Check for required auditing of the audit table as follows:
From SQL*Plus:
select upd, del, object_type from dba_obj_audit_opts
where object_name = 'AUD$';
If the record returned is of object type TABLE and upd(ate) and del(ete) are not = 'A/A', this is a
Finding.
If the record type VIEW is returned and upd and del are = A/A, this is NOT a Finding.
Otherwise, if the record type VIEW is returned and upd and del are NOT = 'A/A', then the
underlying table must be checked for update and delete auditing as follows:
From SQL*Plus:
set long 1000
set wrap on
select text from dba_views where view_name = 'AUD$';
Review the text returned and locate the from table_owner.table_name. This should be located at
the end of the text returned.
Replace table_owner and table_name in the select statement below with the values returned
above.
From SQL*Plus:
8/19/2010
VL05
Page 124 of 130
select upd, del from dba_obj_audit_opts

where owner = 'table_owner' and object_name = 'table_name';
If the value of upd(ate) and del(ete) returned above is NOT equal to 'A/A', this is a Finding.
Fixes:
The only application objects auditing required is for use of the RENAME privilege on database
objects.
Configure auditing on RENAME privilege use by default for newly created objects.
From SQL*Plus:
audit rename on default by access;
If application objects have already been created, the audit rename on object statement should be
issued for all application objects.
From SQL*Plus:
audit rename on [application object name] by access;
Enable auditing of access and activity on audit trail data stored in the database.
From SQL*Plus:
audit update, delete on AUD$ by access;
NOTE: The audit table is by default in the SYSTEM schema, but may have been moved to
another schema.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0002564
DO3612
7
Active
Oracle system privilege assignment
System Privileges should not be granted to PUBLIC.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
DO3612-ORACLE11
Category II
8/19/2010
VL05
Page 125 of 130
Severity
Override
Guidance:
Vulnerability
Discussion:
System privileges can be granted to users and roles and to the user group PUBLIC. All
privileges granted to PUBLIC are accessible to every user in the database. Many of these
privileges convey considerable authority over the database and be granted only to those
persons responsible for administering the database. In general, these privileges should be
granted to roles and then the appropriate roles should be granted to users. System privileges
should never be granted to PUBLIC as this could allow users to compromise the database.
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
System Privileges are granted to PUBLIC.

No
ECLP-1
From SQL*Plus:
select privilege from dba_sys_privs where grantee = 'PUBLIC';
Fixes:
Revoke any system privileges assigned to PUBLIC:
From SQL*Plus:
revoke [system privilege] from PUBLIC;
Replace [system privilege] with the named system privilege.
NOTE: System privileges are not granted to PUBLIC by default and would indicate a custom
action.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0002574
DO3622
6
Active
Oracle roles granted WITH ADMIN OPTION
Oracle roles granted using the WITH ADMIN OPTION should not be granted to unauthorized
accounts.
Comments:
Not a Finding
Not Applicable
Not Reviewed
8/19/2010
VL05
Condition:
Page 126 of 130
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO3622-ORACLE11
Category II
The WITH ADMIN OPTION allows the grantee to grant a role to another database account. Best
security practice restricts the privilege of assigning privileges to authorized personnel. Authorized
personnel include DBA's, object owners, and, where designed and included in the application's
functions, application administrators. Restricting privilege-granting functions to authorized accounts
can help decrease mismanagement of privileges and wrongful assignments to unauthorized
accounts.
Oracle roles granted using the WITH ADMIN OPTION are granted to unauthorized accounts.
Yes
ECLP-1
select grantee||': '||granted_role from dba_role_privs
('DBA', 'SYS', 'SYSTEM', 'WKSYS', 'LBACSYS',
'WMSYS', 'OWBSYS', 'CTXSYS',
'SPATIAL_CSW_ADMIN_USR',
'SPATIAL_WFS_ADMIN_USR',
'FLOWS_030000')
and admin_option = 'YES'
and grantee not in
(select distinct owner from dba_objects)
and grantee not in
(select grantee from dba_role_privs
where granted_role = 'DBA')
order by grantee;
Review the System Security Plan to confirm any grantees listed are IAO-authorized DBA accounts
or application administration roles.
If any grantees listed are not authorized and documented, this is a Finding.
Fixes:
Revoke assignment of roles with the WITH ADMIN OPTION from unauthorized grantees and regrant them without the option if required.
From SQL*Plus:
8/19/2010
VL05
Page 127 of 130
revoke [role name] from [grantee];

grant [role name] to [grantee];
Restrict use of the WITH ADMIN OPTION to authorized administrators.
Document authorized role assignments with the WITH ADMIN OPTION in the System Security
Plan.
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
V0002586
DO3685
7
Active
Oracle O7_DICTIONARY_ACCESSIBILITY parameter
The Oracle O7_DICTIONARY_ACCESSIBILITY parameter should be set to FALSE.
Open
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
DO3685-ORACLE11
Category III
The database data dictionary tables contain the data used by the database for database functions
including database authentication and authorization as well as database configuration and control.
By default, the parameter O7_DICTIONARY_ACCESSIBILITY is set to FALSE to prevent
accounts with the privilege SELECT ANY TABLE from selecting the data dictionary tables. This
setting protects the data dictionary from unintended access authorization by requiring full system
privileges or direct table access permissions.
The Oracle O7_DICTIONARY_ACCESSIBILITY parameter is not set to FALSE.
No
ECAN-1
8/19/2010
VL05
Page 128 of 130

Checks:
From SQL*Plus:
select value from v$parameter where name = 'O7_dictionary_accessibility';
If the value returned is TRUE, this is a Finding.
If the parameter does not exist or the value returned is FALSE, this is Not a Finding.
Fixes:
Disable O7_dictionary_accessibility to restrict access to system tables to users granted privileges
to access objects owned by all users.
From SQL*Plus:
alter system set O7_dictionary_accessibility = FALSE scope = spfile;
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0002589
DO3689
9
Active
Oracle object permission assignment to PUBLIC
Object permissions granted to PUBLIC should be restricted.
Comments:
Not a Finding
Not Applicable
Not Reviewed
Condition:
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
DO3689-ORACLE11
Category II
Permissions on objects may be granted to the user group PUBLIC. Because every database user is
a member of the PUBLIC group, granting object permissions to PUBLIC gives all users in the
database access to that object. In a secure environment, granting object permissions to PUBLIC
should be restricted to those objects that all users are allowed to access. The policy does not
require object permissions assigned to PUBLIC by the installation of Oracle Database server
components be revoked (with exception of the packages listed in DO3475).
Default
8/19/2010
VL05
Page 129 of 130
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
Object permissions granted to PUBLIC are not restricted.

Yes
Review the accounts, objects and permissions as generated. Confirm the permissions for the
objects are documented, authorized and accept as Documentable in VMS.
DCFA-1
select owner ||'.'|| table_name ||':'|| privilege from dba_tab_privs
where grantee = 'PUBLIC'
and owner not in
('SYS', 'CTXSYS', 'MDSYS', 'ODM', 'OLAPSYS', 'MTSSYS',
'ORDPLUGINS', 'ORDSYS', 'SYSTEM', 'WKSYS', 'WMSYS',
'XDB', 'LBACSYS', 'PERFSTAT', 'SYSMAN', 'DMSYS',
'EXFSYS');
If any records that are not Oracle product accounts are returned, are not documented and
authorized, this is a Finding.
NOTE: This check may return false positives where other Oracle product accounts are not
included in the exclusion list.
Fixes:
Revoke any privileges granted to PUBLIC for objects that are not owned by Oracle product
accounts.
From SQL*Plus:
revoke [privilege name] from [user name] on [object name];
Assign permissions to custom application user roles based on job functions:
From SQL*Plus:
grant [privilege name] to [user role] on [object name];
Vulnerability Key:
STIG ID:
Release Number:
Status:
Short Name:
Long Name:
Open
V0002593
DO3696
7
Active
Oracle RESOURCE_LIMIT parameter
The Oracle RESOURCE_LIMIT parameter should be set to TRUE.
Comments:
Not a Finding
Not Applicable
Not Reviewed
8/19/2010
VL05
Condition:
Page 130 of 130
Policy:
All Policies
MAC /
Confidentiality
Classified
Grid:
Sensitive
Public
STIG ID:
Severity:
Severity
Override
Guidance:
Vulnerability
Discussion:
Default
Finding
Details:
Documentable:
Documentable
Explanation:
Responsibility:
References:
Checks:
DO3696-ORACLE11
Category II
The Oracle RESOURCE_LIMIT parameter determines whether resource limits are enforced in
database profiles. If Oracle resource limits are disabled, any defined profile limits will be ignored.
NOTE: This does not apply to password resources.
The Oracle RESOURCE_LIMIT parameter is not set to TRUE.
No
ECLO-1
From SQL*Plus:
select value from v$parameter where name = 'resource_limit';
If the value returned is not set to TRUE, this is a Finding.
Fixes:
Enable resource limit checking on the database.
From SQL*Plus:
alter system set resource_limit = TRUE scope = both;
The above SQL*Plus command will set the parameter to take effect immediately and permanently
at next system startup.
Vulnerability Count - 90
For Official Use Only
8/19/2010

U DB Oracle11 v8r1.8 Checklist 20100827 PDF

Uploaded by

Copyright:

Available Formats

U DB Oracle11 v8r1.8 Checklist 20100827 PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

U DB Oracle11 v8r1.8 Checklist 20100827 PDF

Uploaded by

Copyright:

Available Formats

VL05

For Official Use Only

VL05 - Checklist Report

Oracle Databases 11g (Target: Oracle Databases 11g)

Oracle Databases 11g (Target: Oracle Databases 11g)

Oracle Databases 11g (Target: Oracle Databases 11g)

Vulnerability Key: V0003727

Oracle Databases 11g (Target: Oracle Databases 11g)

order by created, owner, object_name;

Oracle Databases 11g (Target: Oracle Databases 11g)

Required auditing parameters for database auditing are not set.

= 'true', 'os' & 'db' (true = os for backward compatibility)

Oracle Databases 11g (Target: Oracle Databases 11g)

Without preservation, a complete discovery of an attack or suspicious activity may not be

Audit trail data is not retained for one year.

Oracle Databases 11g (Target: Oracle Databases 11g)

data periodically or immediately upon system security events.

Oracle Databases 11g (Target: Oracle Databases 11g)

Oracle Databases 11g (Target: Oracle Databases 11g)

Review access granted to the AUD$ table.

where table_name = 'AUD$'

Oracle Databases 11g (Target: Oracle Databases 11g)

Oracle Databases 11g (Target: Oracle Databases 11g)

Information Assurance Officer

Oracle Databases 11g (Target: Oracle Databases 11g)

Oracle Databases 11g (Target: Oracle Databases 11g)

Changing passwords frequently can thwart password-guessing attempts or re-establish protection

Department of Defense (DOD) Instruction 8500.2, Information Assurance (IA) Implementation

Vulnerability Key: V0003817

Oracle Databases 11g (Target: Oracle Databases 11g)

Oracle Databases 11g (Target: Oracle Databases 11g)

Oracle Databases 11g (Target: Oracle Databases 11g)

If remote interface documentation does not exist or is incomplete, this is a Finding.

Oracle Databases 11g (Target: Oracle Databases 11g)

Department of Defense (DOD) Instruction 8500.2, Information Assurance (IA) Implementation

Oracle Databases 11g (Target: Oracle Databases 11g)

Oracle Databases 11g (Target: Oracle Databases 11g)

Assuran App. A, Enclosure A, Para.5.b (8)

Oracle Databases 11g (Target: Oracle Databases 11g)

The PASSWORD_VERIFY_FUNCTION value specifies a PL/SQL function to be used for

raise_application_error(-20003, 'Password should contain at least two digits');

Oracle Databases 11g (Target: Oracle Databases 11g)

Minimum DBA privilege assignment

Oracle Databases 11g (Target: Oracle Databases 11g)

Oracle Databases 11g (Target: Oracle Databases 11g)

Oracle Databases 11g (Target: Oracle Databases 11g)

Responsibility: Database Administrator

If this database is not a production database, this check is Not a Finding.

Oracle Databases 11g (Target: Oracle Databases 11g)

wrap iname=proc.sql oname=proc.plb

Oracle Databases 11g (Target: Oracle Databases 11g)

Department of Defense (DOD) Directive 8500.1, Information Assurance Para 4.18

Oracle Databases 11g (Target: Oracle Databases 11g)

Replication accounts are granted DBA privileges.

Oracle Databases 11g (Target: Oracle Databases 11g)

Oracle Databases 11g (Target: Oracle Databases 11g)

Oracle Databases 11g (Target: Oracle Databases 11g)

DBMS data files are not dedicated to support individual applications.