control, and governance
control, and governance
May 2010
A False Sense of Security
Auditors shouldn’t rely exclusively on segregation of duties to mitigate risk in modern IT environments.
Gary Lieberman
Senior Vice President, Enterprise Computing
Lazard
Since its inception, IT auditors have relied on segregation of duties (SoD) for compliance with regulatory requirements such as the IT general controls in Section 404 of the U.S. Sarbanes-Oxley Act of 2002. Almost every audit standard published today calls for implementing SoD to varying degrees (see “SoD Guidance” below). But auditors suffer from a false sense of security when they depend so heavily on SoD to govern and mitigate risk in their organization’s technology systems.
Traditionally SoD is used to separate certain key duties so that no one person or group is in a position to perpetuate or conceal wrongdoing. Examples of SoD solutions would be the need for dual signatures on checks or dual launch codes for nuclear arsenals. IT departments implement SoD to segregate the development environment from the production processing environment. The thinking is that compliance with the regulatory controls can be achieved by allowing the people who write the software to access scrubbed test data only. Once they have been formally moved into the production environment, only the programs themselves and not the developers have access to the production data. In ideal conditions the production application support staff only has access to the production data and not to the source code of the software. But one also must consider the system administration staff that oversees the health of both the production and development computer systems: SoD prohibits the same administrators from working in both environments. Most audits will grant passing grades to IT departments that have implemented their controls in this manner, and most chief financial officers and chief information officers would feel secure after a favorable review. Perhaps they shouldn’t.
NO SECURITY IN THE SCRIPT
|
SoD Guidance Several prominent standards and audit guidelines support the use of segregation of duties to address regulatory requirements.
|
One area where the SoD process breaks down is in the nature of modern software development. Previously almost all computer programs were written in a language that required compiling before execution to convert program source code from a human readable form to binary code that is readable and understood by the computer’s operating system. Because binary program code is not human readable and not easily modified, it fits well within the SoD scenario.
Today, though, most software is written in some form of interpretive scripting language such as Shell, Perl, or JavaScript. These programs, called scripts, are human readable and are essentially compiled at execution time. The current distributed processing architecture found in most IT departments consists of applications connecting to and authenticating with other applications such as database systems to retrieve data for processing. Application connection credentials are often stored within the script’s code lines, thus opening up critical application access credentials for viewing by anyone who has read access to the scripts. With 70 percent of all insider attacks aimed at software exploits and 17 percent of those insider attacks being perpetrated by administrators with legitimate privileged access rights, according to CERT’s most-recent Insider Threat Study (PDF), issued in 2004, it becomes clear how critical this area is. It is a simple matter for a system administrator with legitimate privileged access rights to view the script’s code and capture the connection credentials for illicit use.
To understand this better, consider the practice of embedding connection credentials in the script’s code as part of the software design process. Although it has been on the internal audit radar for quite some time, this practice needs to rise to the surface in light of the migration to readable scripts. Audit standards bodies have long stipulated that connection credentials should not be embedded in scripts or automated processes if possible. The issue facing auditors is that this practice is becoming more the norm than the exception. The Open Web Application Security Project, a major player in secure software development, lists hard-coded application credentials eighth on its list of top 10 application vulnerabilities. The SANS Institute, a security research and education organization, lists hard-coded credentials 21st in its list of the Top 25 Most Dangerous Programming Errors. Moreover, Deloitte’s 2009 global security survey of the largest financial institutions, banks, and insurance companies, Protecting What Matters, reported that only 46 percent of all respondents include application security in their software development life cycle and only 35 percent consider their policies and standards to be well defined.
ACTING IN CONCERT
SoD is a good start toward addressing issues arising from modern development practices, but internal auditors and IT security professionals should not rely on it as an end-all solution. Although there is no one-size-fits-all solution, there are basic measures auditors and security professionals should consider to mitigate risk.
- Beware hard-coded connection credentials. Scripts with hard-coded connection credentials should never be allowed to be moved into production. Instead, organizations should implement a good password vault that will hold the credentials and return them to an authenticated script upon request. Before purchasing a solution, organizations should conduct a thorough proof-of-concept review to assure compatibility with their processing environment.
- Review the security of scripts. If the IT department is unable to purchase a password vault, or if it is waiting to implement one, auditors should make sure the security staff, rather than the development staff, reviews all scripts and programs being rolled out to production and changes the connection credentials as part of the standard production roll-out process.
- Make sure a good data loss prevention program is in place. This will go a long way toward preventing sensitive information from exiting the organization should a script with hard-coded connection credentials be exploited. Various products will enable the IT security officer to see who potentially has access to sensitive scripts as well as who has recently accessed those scripts. Some products will report on any scripts that have changed unexpectedly.
- Ensure all privileged access sessions are fully audited and record both keystrokes and returned output. Require that the logs be stored on a different system from that which is being monitored.
- Install log aggregation software to help with monitoring review work. This software collects access and security logs and analyzes them to identify and report on activity patterns that may indicate security breaches.
Although SoD by itself falls far short in protecting sensitive application-to-application connection credentials, combining SoD with several sound measures acting in concert can provide a solid defensive scheme and mitigate risk. Measures such as non-developer oversight and security code reviews embedded in the migration process will provide a significant advantage. More importantly, application security should be augmented by educating the internal audit community to look beyond the initial warm feeling provided by SoD and view every privileged access as a possible threat.
Gary Lieberman is senior vice president of enterprise computing with Lazard, a global investment bank. He is a PHD candidate in computer information sciences, with a specialization in information security, at Nova Southeastern University in Fort Lauderdale, Fla.
To comment on this article, e-mail the author at gary.lieberman@theiia.org.
Share This Article:
Printing Articles on InternalAuditorOnline.org
There is a button at the top of the article that says “Printer Friendly Version.” By clicking that, it should pull up another window that allows for a better printed version of the article.
Posted By: Shannon Steffee
2010-06-24 11:34 AM
IT audit article - a false sense of security
FYI - an article which provides guidance on what to tell clients re: IT security. It suggests that "segregation of duties" is not good enough in IT environments and a lot more work is required to ensure good IT security. Good stuff for the IT audit brochure! Best regards, Vinit
Posted By: Vinit Dayal
2010-06-10 6:55 AM
COMMENT ON THIS ARTICLE
Internal Auditor is pleased to provide you an opportunity to share your thoughts about the articles posted on this site. Some comments may be reprinted elsewhere, online, or offline. We encourage lively, open discussion and only ask that you refrain from personal comments and remarks that are off topic. Internal Auditor reserves the right to edit/remove comments.
To make something bold:
<strong>Text to bold</strong>
To make something italic:
<em>Text to italicize</em>
To make a hyperlink:
<a href="URL">Text to link</a>
