Passwords management for UNIX and Linux systems

By on
Passwords management for UNIX and Linux systems

An unhappy systems administrator who may want to teach a seemingly unappreciative company a lesson. An employee who is passed over for a promotion or a raise. An IT manager who is disappointed by a bonus. A technically savvy database administrator willing to change information in the Oracle Financial Suite for a CEO whose future is riding on the next stock analyst's recommendation.

While any one of these scenarios could serve as the basis of a suspenseful Hollywood thriller, the reality is that each represents a situation in which an employee has privileged access and the ability to thwart weak internal IT controls. As the so-called "trusted" employees are often at the centre of security breaches and incidents of data theft, something that must be addressed as part of a best-practices security measure and to comply with SOX Section 404.

According to a recent study conducted by the Computer Security Institute and the FBI, 80 per cent of respondents surveyed last year reported security incidents involving insider abuse of privileges (up from 64 percent during the previous year). What’s more, a 2005 IDC Research survey found that 31 percent of responding organisations had terminated employees or contractors because of internal security violations.

Taking a closer look at SOX regulations will reveal that Section 404 actually does require organisations to limit and monitor access to specific categories of information and systems. However, many IT administrators are convinced that keeping intruders out of the network constitutes compliance in this case. But providing super-user rights to those who truly do not need them or allowing administrators to share their passwords and privileges for convenience sake needlessly places organisations at risk and could lead to a material weakness.

For those organisations that run mission-critical ERP applications on UNIX or Linux operating systems, this is particularly troublesome because of the inherent security gaps associated with these IT environments. It is commonplace for many users to have complete super-user privileges without justification based on their job classification, duties or role within the IT department. This is a clear violation of security best-practices as it exposes an organisation to potential malicious activity and sabotage that could result in catastrophic information leakage or mistakes that could bring down a network.

Native UNIX and Linux systems simply cannot ensure that the data integrity of financial systems meets the standards required for companies to comply with SOX Section 404 regulations. These systems generally have insecure scripting languages and interpreters, causing multiple security vulnerabilities and points of entry that could be exploited.

To complicate matters, these vulnerabilities differ depending on the version of UNIX or Linux that is running. Even in organisations that are primarily Windows–centric, there are typically ERP applications running on UNIX or Linux systems. It is not uncommon to find strong access controls for the Windows users but unsatisfactory security within the UNIX or Linux data centre.

The administrator accounts in Windows and the super-user account in UNIX and Linux operating systems grant a tremendous amount of access to proprietary systems and information and the IT processes and workflow involving those privileged administrator accounts should be addressed both as a best-practices security measures and to comply with SOX. Organisations must emphasise enforcement of the doctrine of least privilege as they are still sifting through SOX Section 404 audit requirements.

However, many IT managers do not fully understand the implications of unmonitored privileged user accounts and auditing requirements and therefore, they do not see the problem with multiple administrators having access to and sharing privileged account access. In determining who should have access to critical systems and data, it is important to help IT managers and staff understand that IT must have systems and policies in place that create an enterprise-wide, security environment based on role and scope.

Because most IT administrators are trustworthy, organisations must properly manage access rights without completely hampering the IT staff. In recent years, the concept of identity and access management has emerged as a means of addressing insider threat to satisfy SOX regulations and follow best security practices without alienating the IT department.

IAM to the rescue
Identity and access management (IAM) refers to a comprehensive set of solutions used to identify users within an organisation and control their access to systems and information by aligning their designated user rights, identity and role to the correct intellectual property and digital assets.

The super-user accounts often present within UNIX and Linux systems include the ability to create additional accounts, modify system data or perform application and database functions outside the control of the application system for which the account was issued. Because privileged accounts carry elevated capabilities, they must be more closely monitored for misuse, something that can be accomplished by deploying an effective IAM solution.

In most UNIX and Linux environments, users, administrators, developers and testers require access to critical applications and data hosted on a system. In larger organisations, multiple administrators will have varying responsibilities for each machine, requiring multiple people to have super-user access.

To manually set up these kinds of varying levels of responsibilities is often a painstaking task, and native UNIX and Linux systems offer little or no means to control access. What’s more, the ability to track, log and record activities conducted by administrators using super-user credentials is lacking within native UNIX and Linux systems.

Even when the systems are combined with account management subsystems — including Network Information Service (Sun Microsystems' client-server protocol for keeping track of user and host names on a network) or Lightweight Directory Application Protocol (LDAP)—they simply cannot meet the compliance requirements mandated by SOX Section 404.

These subsystems do not provide the level of granular access control to systems and commands needed, and they do not create detailed audit logs to track user activities or control access on a user-by-user or machine-by-machine basis. When the root or super-user password for a particular server is widely known, every user could conceivably have access to that machine, exposing sensitive data to users who have no authority to view or modify it.

Organisations can benefit greatly from an IAM system that ensures only authorised users are able to access proprietary systems and information. An effective IAM solution will also ensure that those authorised to perform various duties with elevated privileges and access will be confined to what their role designates.

Their activities will be recorded and an indelible audit trail will be created. In addition to helping guarantee the integrity of data in financial systems, this is invaluable for forensics and troubleshooting purposes, and it often serves as a deterrent to malicious or unethical behavior. Role-based access can and should be granularly defined to meet compliance and data privacy requirements.

IAM solutions can provide the controls, event notification and identification, monitoring, logging and indelible audit trails necessary to demonstrate separation of duties. Compliance covers the entire IT portfolio and any IAM program implemented should address:
  • Access controls to proprietary information and systems
  • Encryption of data, network traffic and security policies
  • System-wide monitoring for intrusion or tampering from the inside out
  • Methodology and alerting function to spot and respond to intrusion or tampering
  • Indelible logging of events, including keystrokes, input/output and audit trails

If an organisation works within the framework of these best-practices approaches, an IAM solution will allow for an easier implementation and enforcement of security policy related to privileged accounts. These technologies serve as a centrally controlled application for password management for the hundreds—or even thousands—of systems typically running within a Windows/UNIX/Linux network. By making it easier to authenticate users and automate access restriction, organisations will be one step closer to complying with SOX Section 404 regulations.Summary
Deploying firewalls, intrusion detection systems, anti-virus software and other solutions designed to keep external hackers out of the network is a requirement to comply with SOX Section 404. However, study after study reveals that insiders are at the center of most security incidents, and constructing defenses to combat the threat from within is an equally critical component of a security infrastructure that complies with Section 404.

The bottom line is that organisations can and should trust their employees, so long as that trust can be verified. Implementing policies and technologies that limit privileged users’ access to systems and data and record audit trails and enforces separation of duties makes it extremely difficult insiders to perpetrate any misconduct, especially for those enterprises running critical ERP applications on Linux and UNIX systems.

Proactively enacting these changes in business process and deploying IAM solutions will pre-empt malicious activity and help businesses ensure that they address the threat posed by insiders to meet best practices security measure and comply with SOX Section 404 regulations.

Most Read Articles

Log In

|  Forgot your password?