control, and governance
A False Sense of Security
Auditors shouldn’t rely exclusively on segregation of duties to mitigate risk in modern IT environments.
Senior Vice President, Enterprise Computing
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
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.
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.
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 firstname.lastname@example.org.
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.