Controls over IT users for operating systems and DBs 943

  • We have been asked by our auditor to make sure we do have control over IT users acting as administrators or similar for operating systems and databases. Furthermore we have been asked to ensure that we log the activity of all of these people or groups of people.
    Our current implementation of this control is that we have a process in place to grant IT users access to infrastructure, OS and DBs, however we do not log administrator activity for various reasons.
    Is anyone dealing with a similar issue? And what is your response and action to fulfill such a requirement?
    Thanks for your comments.

  • we are looking at options to turn on logging/auditing to capture the activities of administrators. the activities performed by administrators need to be reviewed periodically by managmeent to ensure administrators are only performing activities that have been approved or as part of their normal job. changes need to infrastructure typically go through change control so a comparison can be made to the approved changes. suspect activities need to be investigated.

  • Some other access controls can be designed too…
    Removing the System admin privlidges of DB Admins
    Removal/disabling of Guest accounts
    Classfication of User - like Power users,admins, normal users
    Also a periodic check of admin accounts and password policy enforcement for them is desirable. A lot of system admin do not change the passwords of various admin accounts periodically and with passage of time they are known to eveyone.
    Typicaly for windows environment password of the services which act with Domain admin privileges should follow the same.
    One more control that can be designed is removal of shared Ids.Generally and specifically for network devices sometimes one admin ID is used by mutiple people in the admin team. This renders the logging/auditing ineffective.
    The procedure fo revoking the user access after the activity should also there.

  • I have audited many environments within Sarbanes Compliance. Given the recent PCAOB guidance, now the audit focus would be more on the Risk / Risk potential.
    Given that the Sys Amdin and DB Managers has higher level access and does not get the usual logging and reviewing, the potential risk of misuse and fraud is considered high.
    Some of the good controls to follow is:

    1. Establish a base line of the functions that System Admin and DB Administrators carry out on a regular basis.
    2. Establish a base line as how many designated System Admin/DB Managers exist in your environment. Periodically review this list Vis a Vis with system reports. Obviously to minimize the risk factor, you would restrict the access to absolute necessity.
    3. Conduct a periodic audit (quarterly) of high access accounts to weed out any terminations etc. Improve your procedures to require higher level of management approvals when granting new access to Sys Admins/ DBAs and Domian Admins
    4. Implement stronger password controls for all high level accesses. Obviously you would ensure that the default passwords are changed and new passwords are encrypted where possible.
    5. Turn on the Audit features and logging of the activity where possible. daily review of such activity may not be possible, however explore the opportunity to raise alerts when critical activities are performed / not performed.
      Some the activities related to Database Administration / Management have direct impact on Financial Reporting. In one of my audits, I noticed that a critical database trigger which is supposed to update/purge financial data from 2 systems failed to perform in few occasions. This has direct impact on Revenue Recognition. Later we noticed that the access to critical database objects was given to all programmers.
      So keep in mind that it is not always about Sys Admins / DBA’s having Excess Rights - it is more important to ensure that high level access is appropriately granted, reviewed and restricted.

  • Dear all
    Thank you for your replies, this is truly helpful. All comments are really worth considering, I am just not sure if logging administrator activities reduces risks.
    An administrator can actually alter or partially delete log files, so if this person wants to do harm he/she still could.
    We are currently working to implement additional controls, and your inout will help us to keep it in a pragmatic fashion.

Log in to reply