When I’m preparing for a webcast I usually send the sponsor a copy of the presentation so they can prepare their section. While I’m a huge stickler for keeping my content objective, they also usually provide feedback. Some of it I have to ignore, since I don’t endorse products and won’t “tune” content in ways that break objectivity (I’m quickly worthless if I do that), but I often get good general feedback ranging from spelling errors to legitimate content mistakes.
In prepping for the Oracle webcast on Friday, they caught a big gaping hole that I think is becoming a common mistake (at least, I hope I’m not the only one making it). It’s one of those things I know, but when running through the presentation it’s clear I drifted off track and muddled a couple of concepts.
Although the presentation is about preventative controls for separation of duties, many of my recommendations were really about least privilege. When I talk with people around the industry I’m not the only one who’s started to blur the lines between them.
According to Wikipedia (yes, validated with other sources), separation of duties is defined as:
“Separation of duties (SoD) is the concept of having more than one person required to complete a task. It is alternatively called segregation of duties or, in the political realm, separation of powers.”
Pretty straightforward.
But we often say things along the lines of, “you need to monitor administrators for separation of duties”. Well, when you get down to it that isn’t really SoD since the one user can still technically complete an entire task. We also talk about restricting what users have access to, which is clearly the concept of least privilege. Even auditors I’ve worked with make this mistake, so it isn’t just me.
So I don’t have to completely trash my presentation I’m using an informal term I call, “Real World SoD”. It’s a combination of detective controls, real SoD, and least privilege, Basically, we restrict any single individual from completing a task or having unfettered access without either preventative or detective controls.
Before you nail me in the comments, I’ll be the first to admit that this is not SoD, but for conversation and general discussions I think it’s reasonable to recognize that the common vernacular doesn’t completely match the true definition, and in some cases splitting hairs doesn’t do us any favors.
Just something to keep in mind. True SoD means splitting a task into parts, and we need to be clear about that; but I think it’s okay if we mess up sometimes and talk about multiple people also reviewing a task as a form of SoD. I do think we should be clearer about least privilege vs. SoD, but, again, I’m not going to lose sleep over it if we sometimes drift in our discussions as long as we have the controls in place.
Because that’s the really important part.
<
p style=”text-align:right;font-size:10px;”>Technorati Tags: Least Privilege, Security, Separation of Duties
Reader interactions
4 Replies to “Separation of Duties vs. Concept of Least Privilege”
Why don’‘t we call this something like “monitored operation” and beat the drum that such is a good thing.
[…] Was verwechseln sogar Security-Spezialisten mit 17 Jahren Erfahrung? […]
Rather than post my interpretation of fact, I’ll pose this as a question.
Is there a different term to define the following two scenarios:
– In order to access to the secured room, two people must be present with their keys to unlock the door.
– In order to pass the audit, the auditor must not have a direct stake in the outcome.
In the first scenario, we are separating a single task to two people to avoid a single person causing harm. In my second example we are separating two roles to avoid conflict of interest. Note that both are reducing the impact a single person can have but I think there’s a distinction there. In reading wikipedia (and referenced sources) I think these two controls are blurred quite a bit.
Coming from PKI and crypto controls, the first is usually referred to as an “M of N” control (or “K of N” if you’re from nCipher). The second one is a strict separation of duties (or even separation of roles).
I have a problem with that definition—it implies all tasks require cooperation. Of course, in an organization that takes advantage of separation of duties, some tasks (withdrawing money, or shipping confidential data outside) require multiple parties (the ultimate example being nuclear launch keys), while the majority of tasks should not require coordination, so they can be done efficiently and quickly by the appropriate individual. Sticking with military analogies, this is why personal sidearms and rifles are much more common than crew-served machine guns.
Likewise, you don’‘t want your DBAs to require approval from InfoSec for routine actions, only for those which cross a threshold of sensitivity or risk.
In all the discussion of SoD, it’s worth keeping in mind that it’s a deliberate barrier to job performance, and thus should be carefully measured out as an exception to normal (efficient) workflow where appropriate.
The discussion I’‘ve seen seems to ignore the existence of routine work, which is not cross-checked. I suggest it’s worth being clear about this before some manager tells a DBA that every SQL query requires sign-off “because it’s best practice, you know, for compliance reasons”.