Home | About PassGo | Press Center | When was the last time you completed an audit of your UNIX systems?

When was the last time you completed an audit of your UNIX systems?

With stories about people who have gained illicit access to information, the abuse of privilege becoming more common place in the news and the requirement to comply with ever increasing legislation, such as the Gramm-Leach Bliley Act, the G10 endorsement of Basel II in market areas such as Banking and the Sarbanes-Oxley Act, company directors are under increasing pressure of criminal and civil penalties if they do not demonstrate and provide adequate protection of their digital information.

You might consider that your systems and data are secure; after all, each different system and application requires a secure login and password. But consider the user who writes down all their passwords and then leaves this information open to anyone who walks past, or the system administrator who unwittingly gives a new user access to confidential or sensitive information because they added the user to the wrong group – what then? UNIX system administration is a complex field that requires trade-offs between functionality, security and ease of management. The system administrator’s task is even more difficult in larger environments where users may be spread across multiple ‘flavors’ of the UNIX operating system (including the many versions of Linux and others like BSD), hosted on many different hardware platforms. The system administrator tasked with ensuring the security and integrity of all these systems, must learn a number of dissimilar commands to perform similar functions across different operating systems; a task complicated still further as each command has its own unique format and switches – some with meanings and values that differ across operating systems. With so much to remember, it is inevitable that mistakes will, and do, occur.

When users have been successfully authenticated and granted access to a UNIX system, they need access to a variety of programs and scripts in order to use the resources effectively. If some of these programs and scripts are misused, the consequences could be disastrous for the stability of the UNIX environment, ultimately leading to a loss of revenue and credibility for your company. Should a user (authorized or not) acquire the ‘holy grail’ that is the root password, they can potentially access the entire system. While the majority of individuals are completely trustworthy, there still exists significant scope for undesirable activity, perhaps users manipulating data for their advantage or obtaining confidential information because they have access to root applications, or the exposure of the system to external influences, or even a user who, forgetting they are logged in as root, performs a ‘rm –rf *’ and deletes half the file system before they realize their mistake and kill the command.

How would you begin to trace the user or machine where the security breach originated?

In such cases, the reporting and auditing that exist in the operating system are woefully inadequate and, with only minimal information being retained, it is almost impossible to trace such issues back to a user, machine or even the time these events took place.

The essence of the problem lies in the architecture of the UNIX system, which, unlike its PC MS-Windows counterparts - does not traditionally provide methods of partitioning users or provide access privileges dependant upon their role within the company. Nor do UNIX systems allow delegation of ‘system admin’ commands to the non-system administrator user - an example of this rigid functionality is the inability to permit users to reset the local printer queue as required; instead the issue is reported to the helpdesk who, in turn, pass it on to the already overworked system administrators. How much easier and more productive it would be to allow the user to perform such relatively simple tasks and at the same time free-up the system administrators to perform the ‘real’ tasks required of them.

Consider the following ‘real-life’ scenarios:

Scenario 1

Jim is a system administrator at a large national telecommunications company – with staff shortages he is overworked and very stressed. When Susan joins the company, Jim should have taken the time to register her with the appropriate security level on each individual machine and application to which she needed access. Susan’s manager however, only defined her requirements as “similar to David”. With no simple way for Jim to confirm which applications and authorization David had been granted access to, Jim did the easiest thing and cloned David’s access rights for Susan. However, this erroneously gave Susan access to the company tariff and billing system. Once Susan discovered she had unrestricted access she soon made sure that both her, her family and some friends were able to make telephone calls for free.

Without the software required to perform user-provisioning, the task of registering and de-registering users normally falls to the experts, such as Jim. With mistakes often made in the registration process, due to the complexity of the task and the erroneous information supplied from the business users, helpdesks and technical support groups can be quickly over-whelmed with user administration requests, service-levels cannot be fulfilled and users rarely gain immediate access to the business applications they require. The result is lower productivity and increasing frustration.

PassGo Technologies UNIX Resource Manager and UNIX Privilege Manager products prevent this situation happening by helping to centralize the user administration function. Revisiting our first ‘real-life’ scenario again:

Susan joins the company and Jim is tasked with registering her with the appropriate security level and application access. Susan’s manager defines her requirement as “similar to David”. Jim is quickly able to check David’s access rights and notices that David is provisioned as a normal user across most systems except that he is in the Billing Systems Administrators group. Jim knows that Susan, being a new recruit, shouldn’t be given any Administration privileges and therefore selects to provision her in the ‘standard user’ group. Once selected, Jim can turn his attention to other pressing tasks knowing that the company security policy regarding password ageing, and login restrictions will be applied and enforced without the need for further intervention. Susan will be quickly provisioned across the company’s machines relevant to her needs and granted the appropriate levels of access. When the time comes for Susan to be given greater access, Jim is able to select which applications and on which machines the enhanced access is granted.

Scenario 2

In the second ‘real-life’ scenario, Steve is a skilled technical specialist who has worked in the data centre for Bank of High Street for a number of years. Although technically very good, Steve doesn’t always bring out the best in his colleagues and he is known for his fiery temperament.

Steve recently applied for a Team Management post but was turned down for promotion and feels very hard done by. He knows that he can cause the company pain by logging in as root and deleting some critical ‘secure’ files. The files are eventually recovered from backup, but the bank lost business and was unable to operate key accounts during the recovery. The company IT director demands a report on who or what deleted the files and how this was achieved. The System Administrators attempt to trace the actions of users and applications on the systems involved. Using system logs and network logs they can only determine that a number of users were logged in at the time and that at least one of those was logged in as root, but since root access is required by some users during the normal course of their work this isn’t seen as unusual. The IT Director is not happy that there is no definitive answer and the culprit can’t be identified. The Bank makes sweeping changes to its security policy in an attempt to stop this from happening again. This results in delays and loss of productivity and further revenue losses.

Imagine the same events again, but this time the Bank has installed PassGo Technologies UNIX Privilege Manager to control application access without the need to divulge the root password to the users. Steve is unable to login as root as he no longer knows the root password - he is therefore blocked from deleting the critical files.

But what if Steve still had root access because he performed additional system administration tasks?

He is able to login as root and is allowed to delete the mission critical files. But now, when the System Administrators check to see what happened the UPM keystroke log and replay facility provides the definitive answer required by the IT director. These audit files are safely located on another machine to which Steve never had access – so he is unable to manipulate files to cover his tracks. The logs indicate not only who committed the offence but when and how and, using the replay facility, enables the Bank to identify the security weakness. The Bank still suffers during the recovery of the critical files, but tailors its security policy to ensure that such deliberate actions cannot be performed. Steve is disciplined for his gross misconduct and the Bank is quickly able to provide a full service to its customers without the need for additional delays.

These scenarios represent typical access and privilege control problems that are constantly faced by global businesses. PassGo Technologies UNIX Resource Manager and UNIX Privilege Manager products centralize the user administration function and control access to critical corporate data. Implementing these products as a defence against user error or abuse ensures that you can be in control of security breaches, can recover quickly after the event and most importantly can rapidly bring service and revenue levels back on target.

UNIX Resource Manager and UNIX Privilege Manager give you that all important audit trail that is a requirement of legislation such as the Gramm-Leach Bliley Act, the G10 endorsement of Basel II and the Sarbanes-Oxley Act. The UNIX Resource Manager and UNIX Privilege Manager products provide you with the tools to alleviate some of the pressure to comply with this increased legislation and give you the ability to provide and demonstrate how you are protecting your digital information.