Given the complexity of today’s enterprise applications, it is difficult to clearly understand who can do what in a given system. For example, a typical SAP deployment can utilize thousands of different “t-codes,” each of which provides a specific permission within the application. These codes are put together to create a set of entitlements, and each individual (or process, or bot) accessing the system may have still more combinations of entitlements. To contextualize just how sprawling these entitlements can be within an organization, I recently met with a regional bank that has over 500,000 different roles (or combinations of entitlements) in its legacy mainframe system.
It’s tough to keep track of all of this, and entitlement creep is now a real problem in every organization. Workers move from role to role, picking up entitlements as they move along (but rarely using them). Harried IT teams clone existing access privileges of similar roles for new employees, resulting in unintended extraneous entitlements. It’s hard to manage so many entitlements and roles, and some organizations now dedicate entire teams just to keeping them current and accurate. This entitlement complexity can lead to cybersecurity challenges: does every role have only the necessary access to perform its essential functions, and no more? Over-entitlement is a boon for attackers who compromise accounts and creates insider threat risks—allowing an insider to access data they shouldn’t be able to or, worse yet, exploit “toxic combinations” of access to commit fraud.
Fraud is nothing new. Some suggest the earliest example of fraud dates back to 300 B.C., though small-scale fraud was almost certainly happening long before that. But the opacity of complex applications, coupled with frequent over-entitlement, has opened new avenues, both for engaging in fraud and for covering it up. Bad actors can cloak their actions through layers of permissions, confusing network settings, and a relative lack of oversight. Understanding where the potential for fraud exists and putting the appropriate safeguards in place is essential for today’s organizations, and establishing proper Separation of Duties (SOD) is a critical first step.
The potential for fraud
It’s important to understand the many different ways in which employees can perpetrate fraud shrouded by layers of complexity within the system. The classic example of this would be an employee in accounts receivable who can both submit and approve purchase orders. Such a person could potentially create a vendor, create a purchase order, and approve that purchase order without any oversight. While most people are trustworthy, just one unscrupulous employee could potentially funnel significant sums of money to themselves or a friend or relative. At some companies, purchase orders below a certain dollar value may not even be reviewed. An employee who knows that and is careful to keep their fraudulent activity below that threshold might never be caught.
There are other opportunities for fraud, as well. An employee in charge of posting refunds who has access to the organization’s master data might be able to redirect those funds to their own bank account. In such a case, the company might not become aware of the problem until a customer becomes angry at not receiving a refund. Even then, the culprit might not be easy to identify without a robust internal auditing process. Many are shocked to learn just how easy it can be to perpetrate this type of fraud and how difficult it can be to detect and stop it. The key, then, is prevention—and that’s what SOD aims to achieve.
Creating separation by mapping risk
While separation of duties isn’t necessarily something organizations need to think about on day one, they should have a plan in place to conduct a risk assessment once the business reaches a certain size. When a company is small, there’s some inherent mitigation—when everyone knows each other and can simply walk down the hall (or reach out on Slack) to ask about anything that seems odd. As the business grows, new layers of responsibility are added, and understanding specific roles and the part they play grows more important. The founder doesn’t necessarily know the employees in accounts receivable, and probably wasn’t directly involved in their hiring. As things get less personal, new safeguards are needed.
There’s no universal set of safeguards of course, since every organization is different—but it’s always smart to start with a risk assessment. Understanding and identifying where risk exists within the organization is important. This means mapping out those potential toxic combinations—the overlapping duties that create the potential for fraud. The example of an accounts receivable employee who can create an invoice is one such combination, but there are countless others. Any time a new role is created within the organization, it should be analyzed for potential toxic combinations. This is the core of SOD.
It’s harder than it sounds. While it’s obvious that a receiving clerk shouldn’t be able to create invoices, chances are those entitlements are nested deep within larger roles. The functions and permissions inherent to those roles are not always clear—for instance, there might be a “receiving clerk level one” position, but also a receiving clerk level two, level three, and level four. Those positions likely have different permissions, but that isn’t obvious unless you specifically examine each one. That opacity makes it easy to accidentally create toxic combinations, and it’s why proactively mapping out the permissions and entitlements within each role is critical. A robust identity security solution can help by automating the process of identifying and flagging excessive or overlapping permissions. With potential entitlement combinations numbering in the hundreds of thousands, manually mapping those combinations wouldn’t just be time-consuming—it would be impossible. Automation both improves scalability and eliminates the potential for human error.
Of course, while the toxic combinations that lead to fraud are generally the result of oversight or neglect, that isn’t always the case. Sometimes, they are created maliciously. Even trusted employees shouldn’t be permitted to administer their own permissions—this is why so many organizations have centralized identity governance teams. This too is something that should be mapped as part of any risk assessment.
SOD is not a “set it and forget it” solution
Even if a business believes all toxic combinations have been mapped and remediated, systems evolve which means the controls must evolve too. It’s a good idea to run regular reports to review, for example, all users that have created vendors within the past month and cross-reference it with all users who have posted payment to a vendor. Did anyone do both? That doesn’t necessarily mean fraud occurred, but it means an investigation is warranted. Even if the investigation turns up nothing fraudulent, this can still help identify areas where additional safeguards are needed for proper SOD.
SOD controls themselves should also be reviewed regularly. Technology changes quickly today, and rules that made sense two years ago might be hopelessly outdated today. Organizations must ask, is each mitigating control still effective as designed? Does anything need to be added? Have new functionalities been added to the application that render the existing control obsolete, or are there additional technical data points that need to be added to the SOD policy definition to make it more accurate? Ideally, organizations should set these controls to trigger an automatic review if a “lifecycle event” (such as a new application or piece of functionality) occurs. The control owner can then examine the new information and update the relevant SOD policy accordingly.
This, again, lays bare the need for reliable identity management. Modern identity solutions can put fences around users, policies, and lifecycle events, keeping excessive permissions in check and raising alerts when suspicious activity is detected. If the system sees a security analyst access the general ledger, it will want to know not only why they accessed it, but why they had the permissions needed to do so in the first place. This is the sort of suspicious activity that today’s organizations need to be made aware of quickly so that they can mitigate any security gaps by implementing proper SOD controls.
Driving home the importance of SOD
Separation of duties isn’t always the first thing organizations think of, in part because there are relatively few official requirements around the practice. There are no SOD compliance frameworks, and while SOD factors into popular concepts like zero trust, it is rarely talked about in specific terms. All too often, this means that even companies that are aware of toxic combinations within their systems are not motivated to remediate them.
This is a mistake. The potential for fraud is real, and with it comes the equally real possibility of significant financial losses. An ING employee once famously stole $8.5 million from the financial giant by simply requesting checks for fraudulent companies and keeping them under ING’s fraud detection threshold. But it isn’t just large companies that need to worry. Small businesses, too, can be impacted by fraud—and it often hurts more. Take, for example, the Rhode Island body shop that lost $220,000 when an administrative assistant pocketed insurance checks. While there is no “one-size-fits-all” solution to fraud, establishing stronger SOD policies would make it more difficult to carry out this type of scheme.
Mapping toxic combinations and implementing separation of duties rules doesn’t have to be a painful process. Strong, regularly maintained SOD controls can help organizations identify and remediate those toxic combinations in an efficient and straightforward manner, limiting the potential damage of fraud and identity-based attacks. With the right tools in place, today’s organizations can ensure that employee roles are clearly defined and avoid becoming an easy target for cybercriminals.