Tuesday, April 30, 2013

Security Policies - Part 8

Dear Readers,

My name is Franz Devantier, creator of this blog.  I am an Oracle Certified Professional (OCP DBA 11g) Security DBA.  I will be sharing with you the basic duties of an Oracle DBA, and also some of the undocumented, and not so well known tasks. 

I will make a deal with you:  If you refer me to a company that needs database support, from a few hours per week to full time, and I am able to sign a contract with them.
Then I will give you 10% of the monthly contract or deal price every month.  When the contract ends, and we re-sign the contract, I will again give you 10% of the monthly contract price.  This will go on until the company no longer employs or contracts me or my agents to look after their databases.
I can do this, because that 10% is my marketing budget.  When we re-sign the contract, in the future, it may depend on you giving the thumbs up again, and that is worth 10% of the monthly contract price, to be given to you as commission.


Security Policies  -  Part 8
Install only what is required.
Options and Products
The Oracle Database Server installation has a host of options and products that are in addition to the database server.  Most of these options are on the CD pack.  However you should install only those options that you need, because installing additional products that you don’t use, can compromise your security configuration.  If you perform a Typical installation, then you will automatically install a number of extra products.  It is best to use a Custom installation to avoid installing unnecessary products.  This way you will not need to maintain additional products and options, that you are not going to use.  If you need any additional options or products then you can at any time, install these options and products as required.  If the database has been installed with unnecessary options and products, then you can deinstall what you don’t need.

Sample Schemas
The sample schemas provides a common platform for examples.  The sample schemas are good in a test or development environment, however if you are migrating the database to production, then you should remove the sample schemas, or at least lock the sample schema accounts.  A Production database should not be installed with the sample schemas.

Lock and expire default user accounts.
The Oracle Database Server installs with a number of default or preset database server user accounts.  If you have installed using Database Configuration Assistant (DBCA), then most of the default database accounts are automatically locked and expired.  If you have performed a manual installation of the database, then none of the default users are locked and expired, you will have to do this manually after installing the database.

If these default database user accounts are not locked and expired, then they can be exploited in order to gain unauthorized access to data or disrupt normal database operations.

If you install any additional products, options or components later on, then this can also result in additional default database accounts being created.  DBCA will automatically lock and expire them, but you should check to see that this has been done.  Unlock those accounts that you will be using on a regular basis, and assign a strong, meaningful password to them.  You can use password management to maintain strong passwords on all your unlocked user accounts.

Default Accounts and Status with a Standard Installation using DBCA
Username
Account Status
ANONYMOUS
EXPIRED & LOCKED
CTXSYS
EXPIRED & LOCKED
DBSNMP
EXPIRED & LOCKED
DIP
EXPIRED & LOCKED
DMSYS
EXPIRED & LOCKED
EXFSYS
EXPIRED & LOCKED
HR
EXPIRED & LOCKED
MDDATA
EXPIRED & LOCKED
MDSYS
EXPIRED & LOCKED
MGMT_VIEW
EXPIRED & LOCKED
ODM
EXPIRED & LOCKED
ODM_MTR
EXPIRED & LOCKED
OE
EXPIRED & LOCKED
OLAPSYS
EXPIRED & LOCKED
ORDPLUGINS
EXPIRED & LOCKED
ORDSYS
EXPIRED & LOCKED
OUTLN
EXPIRED & LOCKED
PM
EXPIRED & LOCKED
QS
EXPIRED & LOCKED
QS_ADM
EXPIRED & LOCKED
QS_CB
EXPIRED & LOCKED
QS_CBADM
EXPIRED & LOCKED
QS_CS
EXPIRED & LOCKED
QS_ES
EXPIRED & LOCKED
QS_OS
EXPIRED & LOCKED
QS_WS
EXPIRED & LOCKED
RMAN
EXPIRED & LOCKED
SCOTT
EXPIRED & LOCKED
SH
EXPIRED & LOCKED
SI_INFORMTN_SCHEMA
EXPIRED & LOCKED
SYS
OPEN
SYSMAN
EXPIRED & LOCKED
SYSTEM
OPEN
TSMSYS
EXPIRED & LOCKED
WK_TEST
EXPIRED & LOCKED
WKPROXY
EXPIRED & LOCKED
WKSYS
EXPIRED & LOCKED
WMSYS
EXPIRED & LOCKED
XDB
EXPIRED & LOCKED

If any of the default database server accounts besides SYS and SYSTEM is required to be open for whatever reason, then the DBA, can unlock and activate the account with a new secure password.

Enterprise Manager Accounts
If you install Enterprise Manager then SYSMAN and DBSNMP are also open.  If you configure Enterprise Manager for Central Administration, then the SYSMAN account will also be locked.

Franz Devantier,
Need a database health check, or a security audit?
devantierf@gmail.com

Monday, April 29, 2013

Security Policies - Part 7

Dear Readers,

My name is Franz Devantier, creator of this blog.  I am an Oracle Certified Professional (OCP DBA 11g) Security DBA.  I will be sharing with you the basic duties of an Oracle DBA, and also some of the undocumented, and not so well known tasks. 

I will make a deal with you:  If you refer me to a company that needs database support, from a few hours per week to full time, and I am able to sign a contract with them.
Then I will give you 10% of the monthly contract or deal price every month.  When the contract ends, and we re-sign the contract, I will again give you 10% of the monthly contract price.  This will go on until the company no longer employs or contracts me or my agents to look after their databases.
I can do this, because that 10% is my marketing budget.  When we re-sign the contract, in the future, it may depend on you giving the thumbs up again, and that is worth 10% of the monthly contract price, to be given to you as commission.


Security Policies  -  Part 7
Auditing Policy
Security administrators should define a policy for the auditing procedures of each database.  You may for example, elect to have database auditing disabled, unless questionable activities are suspected.

When auditing is required, you must decide on what level of detail to audit the database.  Usually general system auditing is followed by more specific types of auditing after the origins and the areas of the suspicious activity have been determined.  In addition to standard database auditing, Oracle Database server supports fine-grained auditing using policies that can monitor multiple specific objects, columns, and statements, including INDEX.

A Security Checklist
Security of information and the privacy and protection of corporate assets and data are of pivotal importance in any business.  Oracle database addresses the need for information security by by offering features such as Deep Data Protection, Auditing, Scalable Security, Secure Hosting and Data Exchange.

The Oracle database server leads the industry in security.  In order to maximize the security features offered by Oracle, it is very important that the database itself be well-protected.  Proper use of the security features, plus adherence to the basic security practices will help protect your data investment from threats and attacks.

You should adhere to the recommended industry standard security practices, for operational database deployments.  Consider all the paths that the data travels and assess the threats that impinge on each path and node.  Take steps to minimize or eliminate the threats, and to minimize the consequences of a successful breach of security.

Monitoring and auditing to detect increased threat levels or successful penetration, increases the overall security and subsequent losses.  Monitor to find the weak spots, and audit to analyze what happened, so that the weak spots can be closed, and the damage inflicted by them minimized.

Franz Devantier,
Need a database health check, or a security audit?
devantierf@gmail.com

Sunday, April 28, 2013

Security Policies - Part 6

Dear Readers,

My name is Franz Devantier, creator of this blog.  I am an Oracle Certified Professional (OCP DBA 11g) Security DBA.  I will be sharing with you the basic duties of an Oracle DBA, and also some of the undocumented, and not so well known tasks. 

I will make a deal with you:  If you refer me to a company that needs database support, from a few hours per week to full time, and I am able to sign a contract with them.
Then I will give you 10% of the monthly contract or deal price every month.  When the contract ends, and we re-sign the contract, I will again give you 10% of the monthly contract price.  This will go on until the company no longer employs or contracts me or my agents to look after their databases.
I can do this, because that 10% is my marketing budget.  When we re-sign the contract, in the future, it may depend on you giving the thumbs up again, and that is worth 10% of the monthly contract price, to be given to you as commission.
Contact: Franz

Security Policies  -  Part 6
Password Complexity Verification
You can create the sample Oracle password verification routine, by running the PL/SQL script “utlpwdmg.sql”.  This script is available in $ORACLE_HOME/rdbms/admin/
Basically this is what this script does:
CREATE OR REPLACE FUNCTION verify_function
BEGIN
   -- Check for the minimum length of the password (4 characters in 10g, 8 characters in 11g)
   -- Check if the password is same as the username or username(1-100)
   -- Check if the password is same as the username reversed
   -- Check if the password is the same as server name and or servername(1-100)
   -- Check if the password is too simple. A dictionary of words may be
   -- Check if the password is the same as oracle (1-100)
   -- Check if the password contains at least one letter, one digit
   -- Check if the password differs from the previous password by at least
   RETURN(TRUE);
END;
/

Then the script goes on to alter the default profile.  The important change in the default profile is:
PASSWORD_VERIFY_FUNCTION verify_function;  this means that everytime you change a password, the verify_function will automatically check to see fi your passwords meets the minimal requirements.

ALTER PROFILE DEFAULT LIMIT
PASSWORD_LIFE_TIME 180
PASSWORD_GRACE_TIME 7
PASSWORD_REUSE_TIME UNLIMITED
PASSWORD_REUSE_MAX UNLIMITED
FAILED_LOGIN_ATTEMPTS 10
PASSWORD_LOCK_TIME 1
PASSWORD_VERIFY_FUNCTION verify_function;

The alter user command now has a REPLACE clause, by which users can change their own unexpired passwords.
SQL> ALTER USER fred  IDENTIFIED BY fredx REPLACE fred;
User altered.
SQL> connect fred/fredx
Connected.
SQL>

If the password has already expired, then the user can use the OCIPasswordChange() call or ask the DBA to change the password for them.  A DBA has the privileges to alter any users password without supplying the old one, which is a way of forcing a new password.

Password Verification Routine Formatting Guidelines
You can either use the default password verification routine, or you can enhance the existing one, or write a new one.  You can use PL/SQL or third-party tools for this.

If you use PL/SQL, you must adhere to the following format:
Routine name
(
userid_parameter IN VARCHAR(30),
password_parameter IN VARCHAR (30),
old_password_parameter IN VARCHAR (30)
)
RETURN BOOLEAN

When you have created your new routine, then you must assign it as the password verification routine by using the user profile or the system default profile.  It is good practice to change it first in the default profile, and leave it unspecified in the other profiles, or define it as well in the other profiles.  If it is unspecified, then the value from the default profile will be given.  The password verification routine must be owned by the SYS user.

Franz Devantier,
Need a database health check, or a security audit?
devantierf@gmail.com

Saturday, April 27, 2013

Security Policies - Part 5

Dear Readers,

My name is Franz Devantier, creator of this blog.  I am an Oracle Certified Professional (OCP DBA 11g) Security DBA.  I will be sharing with you the basic duties of an Oracle DBA, and also some of the undocumented, and not so well known tasks. 

I will make a deal with you:  If you refer me to a company that needs database support, from a few hours per week to full time, and I am able to sign a contract with them.
Then I will give you 10% of the monthly contract or deal price every month.  When the contract ends, and we re-sign the contract, I will again give you 10% of the monthly contract price.  This will go on until the company no longer employs or contracts me or my agents to look after their databases.
I can do this, because that 10% is my marketing budget.  When we re-sign the contract, in the future, it may depend on you giving the thumbs up again, and that is worth 10% of the monthly contract price, to be given to you as commission.
Contact: Franz

Security Policies  -  Part 5
Password Management Policy
If the database security depends on passwords, then the passwords must be kept secret at all times.  Passwords are vulnerable to theft, forgery, and misuse.  The Oracle Database server uses a password management policy.  Security officers and DBA’s control the password management policy through user profiles, which enables a greater control over the database security.

You can use the CREATE PROFILE statement to create a user profile.
SQL> CREATE PROFILE demo_profile LIMIT
  2  SESSIONS_PER_USER UNLIMITED
  3  CPU_PER_SESSION UNLIMITED
  4  CPU_PER_CALL 3000
  5  CONNECT_TIME 45
  6  LOGICAL_READS_PER_SESSION DEFAULT
  7  LOGICAL_READS_PER_CALL 1000
  8  PRIVATE_SGA 15K
  9  COMPOSITE_LIMIT 5000000;
Profile created.
SQL>

The profile is assigned to the user with the CREATE USER or ALTER USER statement.
SQL> ALTER USER fred PROFILE demo_profile;
User altered.
SQL>

Account Locking
When a user exceeds a designated number of failed login attempts, then the Oracle Server automatically locks that user account.  In a similar way you can specify the amount of time in days that accounts remain locked.

SQL> CREATE PROFILE demo_profilex LIMIT
  2  FAILED_LOGIN_ATTEMPTS 4
  3  PASSWORD_LOCK_TIME 30;
Profile created.
SQL>
SQL> ALTER USER fred PROFILE demo_profilex;
User altered.
SQL>
If the account does become locked, it will automatically become unlocked again after 30 days, unless it is manually unlocked by the DBA prior to the 30 days completing.  If you had not specified a time interval for unlocking the account, then PASSWORD_LOCK_TIME would assume the value in the default profile.  If you specify PASSWORD_LOCK_TIME UNLIMITED, then you will need to explicitly unlock the account with the ALTER USER statement.
SQL> ALTER USER fred ACCOUNT UNLOCK;
User altered.
SQL>

After a user successfully logs into an account, the unsuccessful login attempt count for the user, is reset to 0.

The security officer can also explicitly lock the account.  If the account is explicitly locked, then it can only be unlocked again explicitly or manually.
SQL> ALTER USER fred ACCOUNT LOCK;
User altered.
SQL>

Password Aging and Expiration
You can use the CREATE PROFILE or ALTER PROFILE statement to specify a maximum lifetime for passwords.
SQL> ALTER PROFILE demo_profile LIMIT PASSWORD_LIFE_TIME 90 PASSWORD_GRACE_TIME 7;
Profile altered.
SQL>

This will result in the password expiring after 90 days, and the user or the DBA will have to change the password.  You could have also specified the grace period in days, during which you can still access the database, but in which time you can change the password.  After the end of this grace period, you will need to ask the DBA to activate your account.

SQL> ALTER USER fred IDENTIFIED BY fred;
User altered.
SQL> connect fred/fred
Connected.
SQL>

Chronology Process of Password Lifetime and Grace Period

Setting the PASSWORD_LIFE_TIME Profile Parameter to a Low Value
There may be some issues when you set the PASSWORD_LIFE_TIME parameter of the CREATE PROFILE or ALTER PROFILE statement to a low value, for example to 1 day. 

If the user is logged in when you make this change, then the users account status will change from OPEN to EXPIRED, with the ORA-28002 message.  You can find a list of the currently logged in user by querying the USERNAME column of the v$session view.
-> If the user is not logged on, when you set PASSWORD_LIFE_TIME to a low value then the users account status does not change, when the user logs in.
-> When you set the profile value to PASSWORD_LIFE_TIME UNLIMITED, this will only affect accounts that have not yet entered their grace period.  The user must change their password, if they are already in the grace period.

Password History
There are two parameters that control the user’s ability to reuse an old password.
Parameter Name
Description and Use
PASSWORD_REUSE_TIME
Requires either of the following:
-> A number specifying how many days, or fraction of a day, between the first use, and next use of a password.
-> UNLIMITED
PASSWORD_REUSE_MAX
Requires either of the following:
-> A number (integer) to specify the number of password changes required before a password can be reused.
-> UNLIMITED

If neither of the above parameters are specified, then the user can reuse passwords at any time, which is a security issue.

If neither of the two parameters is specified as UNLIMITED, then password reuse is allowed, but only after meeting both conditions.

If both parameters are set to UNLIMITED, then Oracle ignores both, and the user can reuse any password at any time.

If you specify DEFAULT for either of the parameters, then Oracle uses the value defined in the DEFAULT profile, which may set all parameters to UNLIMITED.  Oracle by design will use UNLIMITED for any parameter specified as DEFAULT, unless you change the setting for that parameter in the DEFAULT profile.

Franz Devantier,
Need a database health check, or a security audit?
devantierf@gmail.com

Friday, April 26, 2013

Security Policies - Part 4

Dear Readers,

My name is Franz Devantier, creator of this blog.  I am an Oracle Certified Professional (OCP DBA 11g) Security DBA.  I will be sharing with you the basic duties of an Oracle DBA, and also some of the undocumented, and not so well known tasks. 

I will make a deal with you:  If you refer me to a company that needs database support, from a few hours per week to full time, and I am able to sign a contract with them.
Then I will give you 10% of the monthly contract or deal price every month.  When the contract ends, and we re-sign the contract, I will again give you 10% of the monthly contract price.  This will go on until the company no longer employs or contracts me or my agents to look after their databases.
I can do this, because that 10% is my marketing budget.  When we re-sign the contract, in the future, it may depend on you giving the thumbs up again, and that is worth 10% of the monthly contract price, to be given to you as commission.
Contact: Franz

Security Policies  -  Part 4
Application Developer Security
Security DBA’s should define a security policy for application developers using the database.
-> You can grant the privileges to the application user to perform the required functions of creating objects etc.
-> You could require the application developer to submit a request with regards to which objects should be created, and the database administrator can execute the scripts, or create the objects requested.  This is better, because it creates a separation of duties.

Application Developers and Their Privileges
Database application developers need additional privileges to  other users, they need to be able to create tables, create procedures etc.  However the specific privileges that they need should be determined, and granted to them, preferably in the form of a role.  Because you want to restrict the application developers overall capabilities in the database.

Application Developer Environment: Test and Production Databases
It is good practice to restrict development to test databases.  In this way the application developers don’t compete for resources with the users, and they can’t detrimentally affect the production database.
When an application has been thoroughly developed and tested, it is permitted access to the production database, and is made available to the appropriate end users.

Free Versus Controlled Application Development
The DBA, should determine which option to follow, and grant the appropriate privileges.
-> Free Development:  is where an application developer is allowed to create schema objects, including tables, indexes, procedures, packages, and so on.  In this way the application developer has a large measure of independence.
-> Controlled Development: An application developer is not allowed to create new schema objects.  A database administrator, creates all the required objects as required by the application.  The application developer will have to request for the objects to be created.  In this way the database administrator maintains complete control over the creation of objects and space usage of a database, as well as all the access paths to the data.  

Some installations will use one of these options, while most will probably mix things up.  They may allow application developers to create the procedures and packages, while not allow them to create tables and other objects.  A security administrator should base such a decision on a number of factors.
-> The control that the DBA’s need to exercise over the space usage of a database.
-> The control desired over the access paths to the schema objects.
-> If the database used to develop on is purely a test database, then a more liberal development environment can be created, although the resources are still limited, and there needs to be some level of control.

Roles and Privileges for Application Developers
Security administrators can create roles to manage the privileges required by the typical application developer.  For example an application developer role APP_ROLE, may include the CREATE TABLE, CREATE VIEW, CREAT PROCEDURE system privileges.  This role can then be granted to an application developer.  When creating application developer roles keep this in mind.
-> CREATE system privileges are granted to application developers to enable them to create their own objects.  CREATE ANY system privileges, which allow a user to create an object in any user schema, are not usually granted to a developer.  You want to restrict the creation of new objects to the developers account as far as possible.
-> Usually you would not grant object privileges to application developers through roles.  Receiving these privileges through roles, may restrict their usability in creating other objects, such as views and stored procedures.  Mainly it is a practical solution to allow application developers to create their own objects for the purpose of development.

Space Restrictions Imposed on Application Developers
Although application developers may be given the privileges to create their own objects as part of the development process, It is good practice to maintain limits on how much space can be used by an application developer.  You should specifically set limits or restrict access to the following for each application developer.
-> The tablespaces in which the developer can create tables and indexes.
-> The quota for each tablespace accessible to the developer.

Application Administrator Security
In a large database system, with many database applications, you can consider assigning an application administrator.  An application administrator would look after the following types of things.
-> Creating roles for an application and managing the privileges of each application role
-> Creating and managing the objects used by a database application
-> Maintaining and updating the application code and Oracle procedures and packages as needed.  An application administrator may also have been the application developer, and designer of the application.  Or the application administrator could be any individual who is familiar with the database application.

Franz Devantier,
Need a database health check, or a security audit?
devantierf@gmail.com