In the old days, it was simply administrative privilege on Mainframes, root or superuser privilege on Unix and Linux systems, supervisor or admin for NetWare systems, or administrator on Windows systems that cordoned-off access to IT resources into either:
1) you own and can control everything
2) you do NOT own and CANNOT control everything
The architectural limit of today’s technology
The fundamental design of most modern computing systems, including the latest iPhone or Android phone (you have to “root” your phone) either let’s you control everything or you cannot; and either software applications run as privileged kernel-level superuser or administrative processes (and threads) or these run as less privileged user processes (and threads).
Design limit meets the Internet
The fundamental design-concept regarding privilege for information technology has not changed: It’s still based on the idea that you can own the device or not.
In your home this dualism works well if you are trying to prevent your children from causing problems. But, in an enterprise setting with many degrees of freedom and an untold number of interacting processes and IT systems, this simple access-dichotomy inherent in the technology – does not work.
Well, along comes the Internet and Internetworking and its applications from the hardware and link-level to the application-level that get built into every technology platform and application, and it provides an inviting target to miscreants both inside and out of the organization on both sides of the Maginot-line separating enterprise networks from the Internet.
Design limit meets regulatory rules and audits
And then, you have these regulatory and other audits (think PCI, SOX general controls audits, HIPAA audits, Euro Data Privacy, etc) that demand duties and roles be segregated and separated.
In general, most regulations on separation of duties focus on preventing the same people who can approve a transaction NOT be the same people who can initiate a transaction. Otherwise you’d have wholesale fraud and loss.
But these same rules are also extended to focus on making sure the same people who install and maintain IT systems are not the same people who manage security for IT applications and systems.
Even with logging turned-on to capture and record every change that occurs, regulators and auditors frequently want to separate or segregate roles to ensure the fox is not also guarding the hen house.
Solution: technology, organizational or both?
The problem for most of us is that there is NO simple technology solution to the problem. Even the oft-talked about “least privilege” solution that is bandied about by suppliers looking to score points is found to be simplistic or non-scalable: when you look under the covers you find it is difficult to approximate the real world.
This leaves most organizations with using the only ways they can to separate or segregate privileged from unprivileged roles, by artificially restricting who has access to “superuser” or administrative roles. Unfortunately, it’s not always a pretty sight or as clean as it sounds.
For example, relational databases are often installed as “root” and own the boxes on which they are installed. And, often DBA’s who are granted “superuser” rights can basically do whatever they want with the boxes.
Some organizations have gone to the extreme of using specially developed code (often called Role-based Access Control or RBAC) to prevent access to transaction and security logs by DBA’s whereas others have not been required to implement these steps. But the fundamental problem is the underlying architectural limit of “all access or limited access” has not changed with most RBAC extensions. Similar problems (and less common Role-based Access Controls) are being used and tried for network systems, hosts, applications and websites that act as the front-end of transactions (think online banking, etc).
In the face of expensive or strange contortions, many organizations simply reorganize who can do what to which systems: in effect implementing separation of duties the old fashioned way by imposing organizational limits and job duties on what people can or cannot do with IT systems, applications and networks.
Evaluate the risk
There is not one solution for separation of duties that can be applied equally for all organizations. Segregation of duties is an additional cost because it may involve technology and it is likely to increase head count. As a result, a risk assessment should be conducted to determine where separation of duties is necessary: don’t assume your auditor is right until management has had the opportunity to decide whether to accept or mitigate the risks.
So, how do you control the separation or segregation of duties for you organization when it comes to IT systems, networks and applications?
Let us know.
Some additional readings
- Separation of duties guide
- Separation of duties: Controllers Office at UC Berkeley
- Separation of duties and IT security
- Separation of duties in information technology