Using Console Servers to Support Audits Driven by Sarbanes-Oxley

Ron McCarty

The Sarbanes-Oxley Act (SOX), which was passed in 2002, established requirements for public companies to ensure accuracy of their financial reporting. These requirements have created an audit focus point for most IT shops in publicly traded companies.

The SOX Act does not specifically define the particular process or controls that companies and IT must implement. However, the Public Company Accounting Oversight Board, which oversees the accounting portions of the act, recommends use of the COSO framework, which focuses mainly on the accounting aspects of SOX. For IT-related matters, many organizations choose to follow the COBIT framework, which is defined by the ISACA, an information governance organization for auditors and security professionals.

Regardless of framework, there are common themes that IT shops ultimately end up concentrating on from a systems administrator's standpoint. Of these common themes, there are several areas that console servers lend themselves well to supporting: security, incident management, installation, and technical support. Let's examine some of the specific auditing needs that console servers can be used to meet.

Security: Physical

When providing access to the data center and individual systems, a common objective is to ensure that access is given only to those that need it and that the least privileges necessary are granted to an employee for a particular function or job.

Traditionally, in mainframe shops that pre-date open systems, this was achieved through physical segregation where tape drives were kept in one area, CPU resources in another, and front-end processing in yet another area. Tape operators, for example, could access the tape area, but not the CPU area, and system personnel could access the central processing area, but not the tape area.

With open systems, segregation of areas has not always been possible or desired. However, the practice of separation is still a basic security posture and a common audit theme that can minimize security risks.

Console servers can help implement a separation of areas. Console servers can be deployed in areas that have equipment with various support responsibilities and then be used to provide access and segregate the equipment. For example, in a large organization with hardware support teams, console access can be granted to network administrators, systems administrators, and PBX administrators. None of these administrators will have access to another's equipment and can access their own equipment only after provisioning takes place to allow specific console access. Everyone else can be denied access to the area.

For areas with the tightest physical security or remote sites, some console servers provide power management options that allow a server's power to be cycled in those rare circumstances where a system is completely hung.

The console server also builds in an audit trail by allowing activity to be logged. The logs can be stored for reactive use (i.e., when something happens), can be randomly inspected by data center or network security personnel, or can even be monitored by custom tools or a third party to alert based upon particular regular expressions.

Security: Logical

This physical control of the port also lends itself to additional logical controls. For example, many simpler devices and legacy equipment may not have authentication support at the console interface. By forcing all console traffic through console servers, authentication is provided to the console port that did not previously support authentication. Additionally, most console servers support port provisioning based upon user and group membership, so that the combination of authentication and segregation is provided in the most granular fashion possible. On systems that do provide authentication, the console server does not bypass the authentication, so native security measures are also kept in place.

Additional audit objectives of meeting strong password requirements (length, characters, aging, etc.) can also be met. By utilizing many open and industry standards, console servers can typically meet the password requirements of your organization by utilizing password mechanisms already in place, such as secure lightweight directory access protocol (LDAP). This means that even if the device cannot natively support the appropriate strong passwords requirements, the console server can enable the functionality.

If physical security cannot be tightened as much as needed, additional security can be put in place on the console server to monitor loss of signals and system prompts that suggest a system has been disconnected.

Incident Management: Security

Besides the logging mentioned above, console servers can play a role in investigating security incidents by providing an out-of-band method to access the particular device that is being used to monitor the incident. Although the use of out-of-band is not required during an attack, it does make the investigation easier by keeping the IP traffic from the investigation separate from the traffic that is being investigated.

Out-of-band access is required, however, when the decision is made to disconnect the system from the network. If a system is compromised, the organization must weigh the risks of further internal compromises and external attacks, and the choice to disconnect the system from the network is usually made. Without the console access, security professionals and systems administrators must access the system locally, which would draw further unwanted attention to the compromised system.

The console posture shows auditors that the organization takes incidents involving company data seriously but is carrying out investigations discreetly and professionally to increase the likelihood of stopping the incident and identifying the intruder.

For shops that leverage honey pots during security incidents, the console server also provides the needed access to the original system that the honey pot is mimicking.

In addition to the out-of-band use, the console's capturing and buffering capability can be used to capture data during a denial-of-service attack that is causing syslog traffic to not reach its destination. (Syslog uses UDP, so delivery is not guaranteed.) Syslogd can be configured to write output to the console during the attack, ensuring the messaging is captured so that the incident management team can investigate the incident thoroughly.

Many console servers also allow others to watch a session while someone else is carrying out work. This can be a very powerful tool to allow both administrators and security professionals to follow an incident in real time. It can also be used to allow a vendor to participate or allow someone to watch as a vendor carries out particular work during a security incident without the keyboard user and the "watcher" being in the same location. To mitigate risk during these types of incidents and to provide access to lesser-privileged accounts, many console servers provide read-only accounts to limit activity to viewing.

Installation

To help meet audit objectives, many organizations ensure a system turn-up sheet is used to comply with the IT department's security requirements during installation. Often many organizations jump through many procedural hoops to document the fact that particular steps were followed during a turn up to ensure a pass during an audit. For example, the administrator may refer to the checklist, create a ticket for the turn up or particular steps, perform the work, update the ticket, and then update the checklist. This is often done using copy and paste or by manually entering summaries of particular steps.

The console server can be leveraged to automate many of the reporting portions of these tasks. At the basic level, the systems administrator could simply use the console server's ability to capture information to ensure an accurate record is captured and attached to the checklists (soft or hard copies) and tickets. A more advanced approach would be to place wrappers around the captured output during system turn up and have tickets and turn-up checklists generated automatically if the effort is worth it, which will most likely depend on the size of the shop.

Technical Support

Auditors have long realized that information systems are at higher risk during technical support issues because the focus is either on fixing an issue or providing a needed service quickly. To balance the need to fix things quickly, auditors and IT shops recognize the value of change management policies and procedures that are approved as standard methods of dealing with issues before the issue arises.

Often times, a post mortem report is necessary if the technical support was part of a restoration of services incident. However, organizations must spend a lot of time re-hashing the incident to determine which activity took place when. These post mortem reports and the change management tickets that were entered to support the incident are often lacking in the type of detail auditors prefer to see.

Console servers can address the deficiencies of trying to remember specific details by providing a log of what occurred. By requiring personnel to work though the console servers during incidents that will require additional reporting, the post mortem report can be completed much more quickly, with more than enough technical detail to meet any auditor's questions.

Summary

Systems administrators at public companies find themselves spending a lot of time supporting SOX audit initiatives. Often as soon as an internal audit is completed, a kickoff for the next external audit is started, followed by another internal, in a never-ending c ycle to ensure that financial results are reported accurately.

Systems administrators can leverage console servers to meet audit demands, especially in the areas of security, incident management, installation, and technical support as covered here. By tuning existing console servers to meet the auditing requirements or acquiring console servers to meet audit requirements, administrators can increase the likelihood of passing audits.

References

COSO and COBIT -- http://www.sox-online.com/coso_cobit.html

ISACA Web site -- http://www.isaca.org/

Sarbanes-Oxley defined -- http://en.wikipedia.org/wiki/Sarbanes-Oxley_Act

Ronald McCarty is a systems/network professional, freelance author, and founder of Your Net Guard, a company specializing in systems, networking, and security services. Ron completed his undergraduate in CIS with University of Maryland and is currently seeking his graduate degree from Capella University. His free time is spent with his best friend and wife, Claudia, and their two children. Ron can be reached at mccarty@mcwrite.net.