CXL
©2009 CXL - OScan
|
|
CXL ©2009 CXL - OScan
|
| Report for | |
| Company | |
| Business Unit | |
| Location | |
| System | . |
| Report name | reports\myrepo.html |
| Report date | 12-Oct-2009 |
| RISKS |  low risk |
 medium risk |
 high risk |
RESULTS | correct |
medium impact |
major problem |
| 1 | USERSCC | Users |
 |
| Risk |
| In this section we look at some of the user settings which effect the security of the system. |
| 1.1 | STDACC | Standard accounts |
|
|
Risk |
| When Oracle is installed, a number of standard accounts are also included. Many of these have default passwords which are now well known and many have a password which is the same as the user-ID. Accounts with known passwords can be logged into unless they are locked. An 'L' beside an account indicates that it is locked. |
| Actions |
| Examine each of these accounts and change the password. |
| Results |
Standard accounts with unchanged passwords: |
| 1.2 | FAILLOG | Failed logins allowed |
|
|
Risk |
| The number of failed attempts to log in to the user account before the account is locked. This protects the system from people trying to guess passwords. Setting this to 'Unlimited' means that the account is not locked by failed passwords. |
| Actions |
| Set this parameter to a low number between 3 and 6 using profiles. |
| Results |
Failed Login attempts settings. |
| 2 | PASSWORDS | Passwords |
|
| Risk |
| In this section we look at password settings. |
| 2.1 | PWDCHNG | Password last changed |
|
|
Risk |
| This is the date the password was last changed. Passwords that are rarely changed soon become known to other people and segregation of users becomes weakened. |
| Actions |
| Examine those users who have not changed there password recently, particularly any 'system' users. |
| Results |
Password last changed. |
| 2.2 | PWDGRACE | Password grace time |
|
|
Risk |
| The number of days after the grace period begins during which a warning is issued and login is allowed. If the password is not changed during the grace period, the password expires |
| Actions |
| This parameter should be set to a low number of days, less than 10. |
| Results |
Password grace time settings (days). |
| 2.3 | PWDLIFE | Password life time |
|
|
Risk |
| The number of days the same password can be used for authentication. |
| Actions |
| This parameter should be set to your company standards and ideally be less than 60 days. |
| Results |
Password life time (days). |
| 2.4 | PWDLOCK | Password lock time |
|
|
Risk |
| The number of days an account will be locked after the specified number of consecutive failed login attempts defined by FAILED_LOGIN_ATTEMPTS. Setting this to unlimited means that the account can only be unlocked by the database administrator. |
| Actions |
| This parameter should be set at least 15 minutes (0.04 days). |
| Results |
Password lock time settings (days). |
| 2.5 | PWDREUSENO | Password reuse number |
|
|
Risk |
| This is the number of password changes that must occur before the password can be reused. Unlimited means that passwords can never be re-used. |
| Actions |
| This parameter should be set to at least 20 before using the password again. |
| Results |
Password reuse number: |
| 2.6 | PWDREUSETIME | Password reuse time |
|
|
Risk |
| The number of days between reuses of a password. |
| Actions |
| This parameter should be set to at least 200. |
| Results |
Password reuse time (days). |
| 2.7 | PWDVERIFY | Password verify function |
|
|
Risk |
| This specifies a function which is used to verify the password to ensure that it is strong and complex. If set to NULL, no function is used. |
| Actions |
| This should NOT be set to NULL and a verify function should be used. |
| Results |
Password verify function. |
| 3 | PROFILES | User profiles |
|
| Risk |
| In this section we look at the user profile settings. |
| 3.1 | DEFPROF | The DEFAULT profile |
|
|
Risk |
| Each user has a profile and when they don't, the DEFAULT profile is applied. If the default profile has not been modified, many of its security settings will be set to UNLIMITED. These will then be applied to users. |
| Actions |
| Modify the DEFAULT profile so that all settings conform to the system policy. Create profiles for users based on their job function and set security appropriately. |
| Results |
|
| 3.2 | OTHPROF | Other profiles |
|
|
Risk |
| Every user should be grouped into a profile which restricts their actions by means of the various security settings. |
| Actions |
| Ensure that each profile is appropriate for the users duties. |
| Results |
|
| 4 | PRIVILEGES | Privileges |
|
| Risk |
| In this section we look at the system and object privileges available to users. |
| 4.1 | OSYSPRIV | User's system privileges |
|
|
Risk |
| System privileges give users the ability to perform actions on a database. Changes to the databases or the user's job will mean that managing the privileges can become very difficult. |
| Actions |
| We recommend that privileges are not applied directly to user but instead are given to roles and the roles applied to the users. |
| Results |
No users have system privileges. |
| 4.2 | OPQUANY | Users with ANY privilege |
|
|
Risk |
| Privileges that contain the ANY keyword are usually high risk and can be applied to any chosen object. |
| Actions |
| Examine the users shown below and decide if they really need these privileges. |
| Results |
No users have privileges with the ANY keyword. |
| 5 | ROLES | Roles |
|
| Risk |
| In this section we look at some of the user settings which effect the security of the system. |
| 5.1 | OROLDBA | Users granted the DBA Role |
|
|
Risk |
| The DBA role is the most powerful standard role available and has lots of privileges. It should only be applied to certain dtatbase administrators. |
| Actions |
| Examine the users shown below and decide if they really need this role. |
| Results |
The following users have the DBA role. |
| 5.2 | OROLANY | Roles with ANY privilege |
|
|
Risk |
| Privileges that contain the ANY keyword are usually high risk and can be applied to any chosen object. |
| Actions |
| Examine the users shown below and decide if they really need these privileges. |
| Results |
Role Privilege With Admin |
| 5.3 | OROLPWD | Roles without passwords |
|
|
Risk |
| Where a role has important privileges attached to it, these roles should need a password to access them. These roles do not require a password. |
| Actions |
| Examine any sensitive roles and ensure that they are password protected. |
| Results |
The following roles do not have passwords. |
| 5.4 | OROLPUB | Roles granted to PUBLIC |
|
|
Risk |
| Roles, and their associated privileges will be granted to every user of the database. |
| Actions |
| Remove the roles from PUBLIC and assign roles to users instead. |
| Results |
PUBLIC has the following roles. |
| 5.5 | OROLADM | Roles granted with ADMIN |
|
|
Risk |
| Roles granted WITH ADMIN can be passed on to other users. When the original role is revoked, it does not revoke it from the other accounts. This can make it very difficult to manage. |
| Actions |
| Examine the roles granted WITH ADMIN and revoke them and re-GRANT. |
| Results |
User Role with ADMIN |
| 5.6 | OROLCON | Users with the CONNECT role |
|
|
Risk |
| Users with the CONNECT role will have the CREATE TABLE and CREATE DATABASE LINK privileges. These are unnecessary for simply connecting to a database. |
| Actions |
| Create a simple role containing the privilege CREATE SESSION and use this instead. |
| Results |
Users with the CONNECT role. |
| 5.7 | OROLRES | Users with the RESOURCE role |
|
|
Risk |
| This role includes privileges such as UNLIMITED TABLESPACE allowing the user to create objects in any tablespace, regardless of quotas. |
| Actions |
| Create a simple role containing the privileges required and use this instead. |
| Results |
Users with the RESOURCE role. |
| 6 | SYSTEM | System settings |
|
| Risk |
| In this section we look at the system settings. |
| 6.1 | SYSLOGPWDFILE | Remote login password file |
|
|
Risk |
| The parameter 'remote_login_passwordfile' specifies if Oracle checks for a password file and if this password file is shared among databases. Settings: None - Oracle ignores the password file if it exists. Exclusive - Password file is exclusively used by one database. Internal - Used for Oracle Parallel Server Shared - The password file is shared among databases. However, the only users that can be authenticated are sys (and obsoletly: internal). If the password file is shared, only SYS can be added to the password file. |
| Actions |
| Recommended value is 'Exclusive'. |
| Results |
The 'remote_login_passwordfile' parameter is set to EXCLUSIVE. |
| 6.2 | SYSOSAUTH | Remote OS authentication |
|
|
Risk |
| TRUE allows operating system authentication over a non-secure connection and can allow a user to impersonate another operating system user and connect to the database without having to supply a password. |
| Actions |
| Recommended value: FALSE |
| Results |
The 'remote_os_authent' parameter is set to FALSE |
| 6.3 | SYSDATADIC | Data Dictionary Accessibility |
|
|
Risk |
| This parameter, when set to false, prevents the privilege SELECT ANY TABLE from selecting system data tables. |
| Actions |
| Recommended value: FALSE |
| Results |
The current setting for this parameter is FALSE. |