You are on page 1of 11

See Appendix A for consolidated list of scripts used in this audit program.

This program does not fully utilize all data gathered but the data gathered is intended to allow for follow up without additional requests
based on information found during testing.

1.0 IT organisational structure and management support functions


Control Control Guidance on Business risk Test Procedures Testing Results
Objectives Control/Background
1. Segregation Segregation of duties Without appropriate Determine if sufficient segregation of duties and lines of responsibilities are set up
Responsibility of duties reduces the risk of segregation of duties, the between the IT staff.
for the between deliberate fraud or error. organization is exposed
security of security For example, a staff to accidental or malicious
database is responsibilitie members role should not attacks on the database If responsibility for database security is shared (internally), obtain documentation or
restricted s of the be that of DBA as well as configuration and data it procedures manual, and verify with the DBA how the security activities between the
database and having access to the SQL contains. staff are coordinated and controlled.
other roles Server security logs or full
within the access to the operating The extent of this risk will
organization system environment. be determined by the
sensitivity of the data
It is good practice to have contained within the
at least one security database.
administrator, one
operating system
administrator and one
DBA. These activities
should be the responsibility
of at lest 3 different staff IT
members.
2.0 DBMS Configuration
Control Control Guidance on Business risk Test Procedures Testing Results
Objectives Control/Background
1. Developer Developer Separate facilities should be Without appropriate Review the database environment to determine if separate facilities exist for
access should access is in place for developers to segregation of duties, the developers:
be separated restricted develop, or create, organisation is exposed
from the test through applications and programs. to accidental or malicious 1. Enquire from a developer if they can log onto the production or test environment.
and access Developers should not be attacks on the database
production controls able to affect the test or configuration and data it 2. Observe logon to these individual environments.
environments production environment contains. The extent of
during this time. this risk will be 3. Verify this further, by obtaining the list of users for each instance.
determined by the
Note: sensitivity of the data Use the following: select * from sys.sql_logins
contained within the
It is not sufficient to database. User Purpose
have a developer
utilise, for example, a
test machine and log
onto the developer
environment from there 4. Verify developers do not have the ability to update the database configuration.

Developers should have


access to a separate Attributes:
physical area from the test A = Determine if DBA level accounts are used by a developer or any other non
and production DBA user.
environment.
Tickmarks:

USER A

2. Master Fixed role Only DBAs should be There is a risk that users 1. Obtain a query of users that belong to fixed roles.
database is membership granted fixed roles. can inadvertently or
properly is limited intentionally update
protected database configurations, Fixed Role Users
alter database SysAdmin
processing or delete
data. ServerAdmin
SetupAdmin
Security Admin
ProcessAdmin
DbCreator
DiskAdmin
BulkAdmin

2. Determine if users with fixed roles are appropriate.


Control Control Guidance on Business risk Test Procedures Testing Results
Objectives Control/Background
3. Individual Fixed role Only DBAs should be There is a risk that users
database is membership granted fixed roles. can inadvertently or 1. Obtain a query of users that belong to high risk Predefined Roles
properly is limited intentionally update
protected database configurations,
from updates alter database Fixed Role Users
processing or delete db_owner
data.
db_accessadmin
db_datawriter
db_ddladmin
db_securityadmin

2. Determine if users with high risk predefined roles are appropriate.

4. Individual Fixed role Only authorized individuals There is a risk that users
database is membership should be granted these will have access to 1. Obtain a query of users that belong to Predefined Roles that may create a
properly is limited roles. sensitive information that
protected they are not authorized to risk to data privacy (but not to overall database integrity).
from updates view.
Fixed Role Users
db_datareader

2. Determine if users with predefined roles are appropriate.

5. Control Control files Restricting access to the


files should are stored in Only authorised users such control file to authorised 1. Determine where files are stored by viewing the output of the following
be stored in a a secure as the DBA and System personnel will minimise query: select name, physical_name from sys.database_files
secure location administrators should have inappropriate changes to
location access to the control file the file and subsequent 2. Using screenshots or Dumpsec reports (if possible), determine which users
directory and control file. database corruption. have access to this location.

6. Remote External Links to server connections If unauthorized links to 1. Through discussions with the DBA determine if external data connections
access should connections that are not needed should external data sources are are allowed and if so how they are managed and secured.
be limited and are disabled be removed. present, data could be
controlled if by default accessed and updated in
used and when an unintended manner.
used are
controlled in
an
acceptable
manner.
3.0 User Access
Control Control Guidance on Business risk Test Procedures Testing Performed
Objectives Control/Background
1. To ensure All users are Part of obtaining a new Accountability for actions 1. Through discussions with the DBA determine the process of assigning
that all users assigned account should include the taken within the system account details to a user.
are their own signing of an acceptance can only be achieved by
responsible unique use policy. More than likely, assigning all users their 2. Using the output from the user report obtained in procedure 2, determine if
for their own account a person in an organisation own unique account. The all accounts are owned by only one individual.
actions which is will sign such an agreement practice of sharing
accountable before they commence accounts or using the 3. Determine if default accounts have been properly secured.
to them and work. same account name for
for which different individuals
they are The security administrator decreases the level of
responsible should ensure: accountability when
irregular, unauthorised
Access policy and and inappropriate system
procedure exists and is actions have been taken.
current

Whenever a new user


requires access to the
system, they are
assigned their own
account for which they
are responsible no
sharing of account
identifiers

Default admin accounts


should be renamed and
guest accounts or other
unneeded accounts
should be removed.
2.Password Windows Windows password Allowing accounts to use 1. Obtain evidence of the authentication method being used (use output from
management Authenticatio requirements should at a weak password controls select * from Sys.SQL_Logins).
controls are in used should minimum enforce a increases the risk that an
place be used minimum password length, unauthorised user will 2. Obtain evidence of password control settings on the server that hosts the
when password expiration gain access to the SQL Instance (Dumpsec or screen shots).
possible to interval, password history, system.
support failed login attempt lockouts 3. Obtain password and security control policy document.
appropriate and a reasonable span of
password time before password 4. Review the evidence provided in steps one and two above to determine if the
control attempt counter and/or
system meets the policy requirements found in the policy obtained in step three
settings. If locked out accounts are
above.
mixed mode reset.
or SQL
Authenticatio
n is used,
user
accounts will
Control Control Guidance on Business risk Test Procedures Testing Performed
Objectives Control/Background
not be
required to
use complex
passwords
that comply
with IT
policies.
3.To ensure The As part of the SQL Not changing these 1. Ask the DBA if the default password for SQL Server logins (for mixed mode and
that all SQL passwords installation process, the account passwords from local accounts) have been set according to IT policy.
accounts have for SQL following accounts are the default values
appropriate Authenticatio created: increases the risk that an 2. Obtain the Blank_Passwords query for the database being evaluated. (Select
passwords n accounts unauthorised person will name from sys.sql_logins where pwdcompare('', password_hash) = 1)
have been SA gain access to the
set Local/Administrators (local system 3. Obtain the local password security policy.
according to accounts)
policy 4. Verify all accounts have passwords set.
The passwords for the
DEFAULT accounts should
take into consideration
minimum or good practice
password requirements.

Any additional local


accounts assigned should
also follow this practice.
4.To ensure Access to Users that belong to groups Database could Inspect the user listing and determine if any default local groups are given access to
that only the database that inherit access to the potentially be the database that would give groups of inappropriate local or active directory users
appropriate must be SQL server through active compromised by access to the database.
individuals are restricted directory may have too someone other than the
granted much access. intended users.
access

5. Control over Accounts Vendors may require By not creating a Determine who the vendors are and if they have had access previously to the
vendor access created for system access for temporary vendor database. Confirm this via review of the USERS report.
use by emergency, maintenance or account decreases the
vendors are troubleshooting purposes. accountability of their
temporary work.
accounts Although vendors may
that are require the use of an Not removing a vendor
immediately existing account, good account immediately
removed practice says that they increases the risk that the
upon should be assigned a account will be used to
completion temporary account that can gain unauthorised access
of the be removed upon by the vendor or another
vendor completion of their party.
activities activities.
4.0 Roles, grants and privileges

Control Control Guidance on Business Risk Test Procedures Exceptions


Objectives Control/Background
1. To ensure Roles are A role is a named By not creating roles 1. Discuss the development of roles with the DBA
that roles have used collection of system and designed specifically for
been appropriate object privileges. A role user functions, increases
established for ly to may be assigned to a user, the risk that privileges will 2. Verify this by evaluating the output from the following SQL Commands/Queries:
granting access manage but a user cannot be be assigned
user assigned to a role. For inappropriately and users EXEC sp_helpuser, EXEC sp_helpsrvrolemember, EXEC sp_srvrolepermission,
access to example: users can log in are able to obtain access SELECT * FROM sys.database_permissions
the system to the database; roles to data in which they have
cannot log in to the no functional need.
database.

The purpose of having


roles is to group logically
associated privileges and
allow those privileges to
be passed to a user by
referencing a role.

Roles may be created for


the following users so that
their actions can be
controlled

DBA
Developer
General business
user
Operator
Process

Specific roles should be


developed for each type of
user (including privileged
users).

6.0 Change Control


Control Control Guidance on Business Risk Test Procedures Exceptions
Objectives Control/Background
1. To ensure Production If the applications test Production applications 1. Discuss with the IT administrator which databases are authorized to be
test and database database environment is could become running on the respective SQL server.
production servers host located on the same server unavailable.
facilities are only as production unplanned
logically and authorized downtime could occur in
physically production production during the 2. Validate that only appropriate databases are found by reviewing the outout
segregated. databases and development and/or quality from the following query SELECT * FROM sys.databases
are not shared assurance phases.
with test or QA
environments.
2. To ensure Stored dbo.sysdtspackages Unauthorized or untested 1. Discuss with the IT administrator how database objects are used on the
changes to the procedures, Data transformation services Changes made directly to respective SQL server and how changes to these objects are managed.
database data may be used to process the database objects
configuration transformation batches of data collected on could result in data 2. Using the data collected from the following SQL statements, SELECT *
are tested and services a scheduled basis. The integrity issues. FROM sys.sysobjects and SELECT * FROM dbo.sysdtspackages,
authorized prior (content and schedule and the determine if updates were made to relevant objects during the audit
to production schedule), programmed logic behind of period.
implementation triggers and these packages could effect
schema data integrity. 3. Select a sample of changes and determine if appropriate change
changes follow management procedures were followed.
a the IT sys.sysobjects
change Stored procedures execute
management code that could be used to
policy. process system data or
system alerts and might be
used by the application itself
or called by other database
objects.

Triggers execute based on


defined conditions and could
be used to process system
data.

The database schema is the


database structure itself and
if updated could effect the
way the database
operates/stores information.
For example a schema
change could effect data
types used in fields, data
relationships, data indexes,
database links, etc.

C = CHECK constraint
D = Default or DEFAULT
constraint
Control Control Guidance on Business Risk Test Procedures Exceptions
Objectives Control/Background
F = FOREIGN KEY constraint
L = Log
FN = Scalar function
IF = Inlined table-function
P = Stored procedure
PK = PRIMARY KEY
constraint (type is K)
RF = Replication filter stored
procedure
S = System table
TF = Table function
TR = Trigger
U = User table
UQ = UNIQUE constraint
(type is K)
V = View
X = Extended stored
procedure

3. To ensure Database The IT department should 1. Review naming conventions leveraged by evaluating object naming
object usage, administration have a documented standard standards used (review output from SELECT * FROM
naming and to govern acceptable sys.sysobjects)
conventions programming database object usage,
and relevant follow naming conventions and 2. Interview management to understand if naming conventions
coding established IT coding standards. leveraged follow departmental standards and if these standards are
comments guidelines that properly documented.
follow ensure When database field
predefined adequate updates/additions or coding is
department technical required, it should be
rules. documentation consistently documented to
of the ensure any DBA or database
database programmer can easily
environment. determine the purpose of the
related objects which will
ensure effective and efficient
troubleshooting when the
database is not operating as
intended and will also server
as vehicle for a smooth
transition of responsibilities
within the organizations DBA
function.

7.0 Audit
Control Control Guidance on Business Risk Test Procedures Exceptions
Objectives Control/Background
1. Management Auditing is Database auditing is the The absence of recording 1. Discuss with the administrator if the audit function within SQL Server is
should monitor enabled and monitoring and recording of important events in the being utilised
functions or monitored on activities occurring within adatabase increases the
activities on the regular basis database. You typically auditrisk that unauthorised
database to ensure that no system actions, such as
unauthorised users are deleting or modifying 2. Confirm this by reviewing the Logging query to determine if the correct
removing data from the data sensitive data, or access parameter has been set.
dictionary or accessing tables
attempts may not be
they should not have the identified and resolved in
privileges to see. You may a timely manner.
also want to audit specific Further, auditing can be
tables to help determine the useful for gathering
volume of access occurring athistorical data for
peak times. particular database
activities.
2. Management Auditing is There are several different Auditing actions 1. List all the audit options set for all system privileges in the database:
should monitor enabled and types of auditing forms. One undertaken by persons
privileged monitored on of these is using the system
activities on the regular basis administrator privileges 2. Verify that the use of all sensitive system privilege commands are audited
database System level or reduces the likelihood of
privileged auditing inappropriate use.

Privilege auditing audits the The absence of


use of system privileges such monitoring and review of
as CREATE TABLE or DROP important events in the
TABLE. database increases the
risk that unauthorised
system actions, such as
deleting or modifying
sensitive data, or access
attempts may not be
identified and resolved in
a timely manner.
Further, auditing can be
useful for gathering
historical data for
particular database
activities.
3.Activities of DBA activity is DBA activity should be Although a large amount Review the process by which the DBA is audited / monitored.
privileges users monitored and monitored. of reliance is generally
are monitored reviewed placed on the DBA, the
on a regular DBA should be reviewed
basis or audited. This is also
important where the DBA
function is outsourced
(but where the system is
onsite), as the DBA
effectively has complete
Control Control Guidance on Business Risk Test Procedures Exceptions
Objectives Control/Background
access to all of the
business records.
4. User access Reports are User profiles should be based Inappropriate system Review the process for confirming that access levels are commensurate with
is run to review on job functions and roles. level access increases employees job responsibilities.
commensurate user access the risk of unauthorised
with their roles levels or accidental error or
and fraud.
responsibilities
5. Access Access Access failures refers to the The number of access Review the process by which access failures are detected and investigated.
failures are attempts to the number of attempts a user ID attempts could indicate
monitored and database are has to access the database in an attempt at hacking
investigated recorded and one sitting. into the database which,
monitored if successful, could
compromise the integrity,
availability and
confidentiality of the
database.
Appendix A
Instruction: Copy all commands below into a text file. The SQL DBA should run this as a .sql script using the query manager tool and should select output to text file (there may be too many results to export
to a grid and you could lose valuable results)

use msdb

SELECT 'SQL Logins found on Server' as hdr


SELECT '----------------------------------------------------------------' as hdr
select * from Sys.SQL_Logins

SELECT 'Check for blank passwords' as hdr


SELECT '----------------------------------------------------------------' as hdr
Select name from sys.sql_logins where pwdcompare('', password_hash) = 1

SELECT 'SQL Databases hosted on Server' as hdr


SELECT '----------------------------------------------------------------' as hdr
SELECT * FROM sys.databases

SELECT 'SQL Objects found on Server ' as hdr


SELECT '----------------------------------------------------------------' as hdr
SELECT * FROM sys.sysobjects

SELECT 'SQL DTS packages found on Server' as hdr


SELECT '----------------------------------------------------------------' as hdr
SELECT * FROM dbo.sysdtspackages

EXEC sp_MSForEachTable '


IF EXISTS(SELECT 1 FROM sysobjects WHERE xtype = ''TR'' AND parent_obj = (
SELECT id FROM sysobjects WHERE name = PARSENAME(''?'', 1)))
BEGIN
PRINT ''?''
EXEC sp_helpTrigger ''?''
END'

SELECT 'Information related to tables in schema found on Server' as hdr


SELECT '----------------------------------------------------------------' as hdr
SELECT * FROM information_schema.tables

SELECT 'Physical Location of SQL Server .mdf, .lpf on disk' as hdr


SELECT '----------------------------------------------------------------' as hdr
select name, physical_name from sys.database_files

SELECT 'Roles found for databases on Server' as hdr


SELECT '----------------------------------------------------------------' as hdr
EXEC sp_helpuser

SELECT 'Roles membership found for databases on Server' as hdr


SELECT '----------------------------------------------------------------' as hdr
EXEC sp_helpsrvrolemember

SELECT 'Role permissions found for databases on Server' as hdr


SELECT '----------------------------------------------------------------' as hdr
EXEC sp_srvrolepermission

SELECT 'Database permissions found for databases on Server' as hdr


SELECT '----------------------------------------------------------------' as hdr
SELECT * FROM sys.database_permissions

You might also like