The Realities of Trying to Control
System Support Personnel
By: Mitchell H. Levine, CISA
Audit Serve, Inc.
Regardless if you are in a large mainframe or distributed environment, support personnel having privileged system access is vulnerability that needs to be evaluated and controlled where possible. In order to support the system at the OS and database levels, these support personnel are assigned system-level privileges that permit them in most technology environment to administer access rights, control the system operation environment and update all data.
The size of the environment (i.e., number of servers and databases) in many cases determines the ability to have a sufficient number of support personnel to provide a separation of duties between the OS level and the database level. Within the mainframe environment, additional staff allows for separation of duties between the Z/OS system programmer, the CICS system programmer and the job scheduling areas. Also, the organizational structure determines the ability to establish a proper separation of duties. If the database administrators (DBAs) are embedded within the business areas, then the ability to establish a proper separation of duties between the application DBAs which write the database stored procedures and the system DBAs is reduced since these functions will be combined into one. Normally, in a centralized database system support organizational structure, the system DBAs elevate the application initiated database structural changes allowing for the application developers to be restricted from updating the production environment.
The centralized organization structure for the database support areas allows for the separation of duties between application development and the deployment of these changes to the production environment. The System DBAs job function includes keeping the database environment up and running within performance SLA requirements but does require update to data unless there is a need to restore data after a corruption. However, there are instances in which direct changes to data need to be made to resolve a data error which are initiated by application support personnel. In this case the system DBAs are just elevating the SQL scripts which are written by the application development support personnel. Unfortunately, the database system privileges provided by the various database technologies do not provide the necessary separation of duties.
The ability to monitor the activities of System DBAs based on the audit trails provided “out-of-the-box” by the database vendors is limited. The database vendors provide the ability to enable audit trails to log insert, update and deletes to tables. In addition, database technologies such as Oracle and SQL Server also provide reporting facilities which can be used to develop custom reports to allow organization to easily monitor specific types of activities. However, an investment is required to build these audit trail collection processes, system operational components to restart the audit trail processes when the database is restarted and the overall development of these reports which includes distinguishing between authorized and unauthorized activity. The one catch is that the DBAs have the ability to disrupt and alter the data contained in the audit trail files. Additional control measures need to be established to preserve the integrity of these audit trails which is some cases is not possible for certain database technologies. In addition, certain database technologies such as DB2 Mainframe do not provide audit trails that identify changes which are made at the table level.
The control of system programmers in a mainframe environment is even more difficult since they require full access to the environment to apply the system changes via SMP. Windows provides audit trails which can be used to identify changes made by the domain administrator. However, once again, the audit trails do not provide the ability to identify the actual data changes which are made.
Overall, the reasonable detective review process which can be deployed is to identify when an update action has been made by a support person and ensuring that there is authorized request to support their action. Request handling and change management processes need to be established for all types of changes within a system environment which is not the case in most IT environments.
Many organizations have taken the approach that the system support personnel are trusted personnel and therefore do not have to account for each system change they make. Each organization needs to choose the degree of control they want to have within the system support area. Unfortunately, with the reduction of IT staff, there less separation of duties within an IT organization.