Security

As a decision maker in your IT organization, you're aware that your Linux systems share is growing (if your enterprise follows today's business trend). Linux installations are now available on every major hardware platform. New projects in development include Linux systems in an increasing share, and you're challenged with incorporating these Linux systems seamlessly into your operations and business processing.

These Linux systems must also now be included as part of your IT audit. IT audits are increasingly performed by cross-functional teams rather than by operations, networks, applications, or database management teams. The cross-functional audit teams have the scope and purview to examine each area of operations. Since your skilled operations teams aren't responsible for policing their own house, they can remain focused on their core skill sets.

The audit teams make scheduled passes, with strategic focus on physical security, network security, applications security, systems security, and whatever else is part of your enterprise security plan. The report is digested and parsed by the audit team leader or information security manager, who tactfully disseminates the information to the appropriate team leaders.

The first challenge emerging from this vision of corporate information systems unity is that the operations teams will potentially mistrust, hate, fear, or otherwise loathe the audit teams. This humanistic certainty is based on the perception that someone is trying to find something wrong so that blame can be assigned. Overcoming this challenge, while not a typical strategic audit goal, is important since you want the audit teams to have unfettered access, and you want their work to be supported and adopted by the operations teams. The audit teams' reports must become meaningful input for operations teams, who will review a report and mitigate the threats instead of putting out fires later because important audit information was not heeded.

Using your vision, sensibility, and other executive powers, you've attained respectful buy-in from the teams - you can now move forward to meet other challenges.

The Audit

One problem identified during Linux audits is that too many people know the root password and other elevated-privilege account passwords. These passwords are the electronic keys to the kingdom in Linux, and taking back control of these accounts is a top audit priority. Typically, everyone who has the root password knows why they shouldn't pass it out or overuse it.

There's limited accountability in most native Linux operating systems, including the lack of a cogent audit trail. The native auditability is primarily centered around the syslog and sulog facilities, which cannot describe the interactive actions of the root user with the system at the level required by the HIPPA, Sarbanes-Oxley, and NISPOM Chapter 8 requirements, to mention only a few. For example, Figure 1 shows a sample sulog, revealing a not very detailed snapshot of users using su on a system.

While they're better than nothing, the sample log entries don't describe what actions were taken after the SU command occurred. (For the uninitiated, the + or - tells you if the SU request was successful.)

The syslog example may be roughly equivalent (see Figure 2).

The example in Figure 2 also indicates privilege being elevated, but does not describe (or require) a reason. Additionally, the file(s) produced by the syslog daemon may contain information not germane to your audit, but again, some information is certainly better than nothing. You can significantly improve the auditability in your enterprise by adding third-party software that captures all standard input, output, and errors, including everything the user does with the elevated privilege.

The example below is from a policy created on a Linux system (salmon.mydomain. com), using a Symark product called PowerBroker, (version 3.2.1). It provides a root shell for any user authorized to run the command pbrun GIMMIEROOT. The policy creates an audit file akin to others available in some third-party products to give you more auditability when users gain or use elevated privilege. This particular product will log all standard input, output, and errors, as well as a complete report regarding the secured task:

$ pbrun GIMMIEROOT
Enter your reason for accessing this policy:
I need to edit the /etc/passwd file

Figure 3 shows what the resultant logfile includes. Note that the "who, what, when, where, and why" are evident in the log output.

I truncated the log file, but you can see that your audit team has the ability to see it, and to tell the who, what, when, where, and why for any elevated-privilege or vital-asset access. In addition to third-party products, Linux vendors are working hard to provide this functionality. This functionality significantly improves your teams' ability to take back the root and other elevated-privilege accounts by granting elevated privilege only when the user accesses certain commands or assets (within their normal job descriptions, for example). When access is complete, normal privilege resumes, and the user never knows the elevated password.

So you're familiar with elevated-access audit control; is your audit team is as well? Basic audit tenants include reading the documentation to determine what to audit, but what documentation do you have that describes who can access what, when, where, and why?

Your systems, applications, and networks team can collaborate to create a document like Table 1.

Your teams may have used any visualization method, but the output is a matrix of your systems (vertical axis), and your user community (horizontal axis). Notice that each login/access method is described, as well as which system each user can access, from which system, by which method. Once users are on the systems, executable commands are listed, as well as any elevated privilege required. With this documentation, your audit team now knows which systems to go to, which accounts to scrutinize, which commands should normally be allowed as the user, and which commands require elevated privilege. This documentation is simple but effective in meeting the requirement to report upward and manage outward.

Another important problem that surfaces in a Linux audit is the publication of passwords, which often happens inadvertently via secure applications scripts (Web startup or shutdown, middleware startup or shutdown, database startup or shutdown, etc.).

Information synchronization routines (such as NIS or LDAP v2) also place assets at risk, as they pass account, system, and other enterprise information around the LAN or WAN in clear case. (In the case of passwords specifically, the encrypted value is sent, but agile information bandits know the difference between a crypt, bigcrypt, or MD-5 hash. When the rest of the information is in clear case, encrypting only the password may provide little safety.)

Once passwords are obtained by a nontrusted source (someone leaves a file containing a password world-readable, for example), valuable assets are at risk on numerous fronts, including easy access to critical files/data. When an asset can be accessed by a user in masquerade, the asset is at risk. The insertion of a Trojan program, the destruction of an application, and the alteration of data are all undesirable options. Whether compromised by the pad of paper in the machine room, the e-mail to the group alias with a defunct (but still receptive) recipient, the generic account password used by consultants nationwide when installing the new software on your enterprise server, or some other method, the untrusted source now has the ability to log in to one or more systems as someone other than themselves. No audit could save you at this point, as activity performed under the guise of a trusted user is now suspect.

Fortunately, your systems audit includes the regular checking for ownership, permissions, checksums, and other embedded safety mechanisms to keep data and applications in a known good state. Program files, executables, even operating system and patch levels are being recorded and compared from audit to audit, and maintained at the most current secure levels. The LDAP directory is scrutinized for the dysfunction that occurs between Human Resources and Information Systems, causing transferred or even terminated employees to be removed to systems, but allowed to remain in the LDAP directory. This step eliminates the ability for a transferred or terminated employee to gain access to assets via an LDAP-credentialed application. You have delegated and empowered effectively, your audit team is passing back the appropriate report to the systems managers, and the integrity of the systems and programs is secure.

Conclusion

As a quick summary, your internal teams periodically perform these audits:

• Physical security
• Operating system
• Network security
• Others as you require

Each team has a specific focus and reports to you for dissemination and mitigation. A periodic review of your documentation will reveal newly emerging systems, network components, or applications requiring audits, and your appropriate team will incorporate them as needed. The process feeds itself, as each successive audit both addresses issues and reveals an emerging strength of operations as a cohesive unit, with assets protected in concentric rings of recurring audits.

Your charter to your auditors is multifold, as they assess each aspect of today's increasingly complex information systems nervous system. The audits should be periodic, focused on a specific aspect of the larger picture, and as unintrusive as possible. They should yield a systematic and repeatable report, which is then passed back into the system for assessment and mitigation. Your audit teams use a documentation tool to determine who, what, and how to audit your assets, and the result is that the external audit becomes a quality checkpoint rather than an item causing worry, fear, or loathing.