Organizations sometimes forget to segregate—or separate--duties. It’s a dangerous information security oversight.

4 Min Read
Architecture lines under the bridge, Elevated expressway,The curve of bridge in Bangkok, Thailand.
Getty Images

Segregation of duties is a fundamental information security practice. In simple terms, it means you split out important tasks between two or more people. This prevents one person from getting drunk on all the power they wield, and also prevents one person from making a mistake that can have undesired consequences.

One of the best examples of segregation of duties can be seen in movies when it comes to launching nuclear missiles. The system relies on two people on opposite sides of the console to put in and turn their keys at the same time. This segregation, or separation, of duties ensures that one person can’t launch a nuclear missile on his or her own.

Segregation of duties works best when there is a clearly defined function and where there is some physical separation.

For example, in a call center or banking app, a junior administrator may be able to authorize payments up to $500, but anything above that would need supervisor’s approval. The junior admin can enter details and send them off to the supervisor, who can then approve or decline payment.

But, in many cases, the broader application can sometimes have some flaws.

In one of my first jobs in IT security, our team implemented a process for separating duties whenever a new HSM key (key change ceremony) needed to be loaded.

I worked on a team that had one half of the password to complete this task, while another team held the other half. Much like the end of the film “Bulletproof Monk,” I even had my half of the password tattooed on my back. (I still don’t know what it says to this day.)

Once a project was underway, I’d have to travel across the country to the data center with my half of the password in order to change the key with the help of a colleague.

The only problem with that was … Have you ever worked on a project? They’re never on time–always delayed. And data centers are cold!

One time I sat in a data center with another guy who was clearly more experienced than I with this kind of thing. He was sitting under a blanket he’d brought, reading his book and munching on some snacks. What’s wrong with this scenario? Other than that I didn’t have a blanket or snacks, there was the fact that we had both traveled from different parts of the country, each with our half of the password, only to sit together for hours. This invalidated all the expensive measures taken to segregate the two halves of the password.

Even worse, I had no idea what I was doing or how to do it. I was told the documentation was up to date and easy to follow, but documentation being up to date was one of the biggest lies our team told. So, I ended up having to ask my colleague to help me out–which inevitably meant I gave him my half of the password and asked him to enter it. Yeah, separation of duties kind of fell apart right there.

Having said that, those were simpler times–there was no bring your own device, and there certainly wasn’t anything hosted in the cloud.

Many times when organizations adopt cloud apps, they overlook segregating duties or defining job functions for role-based access control (RBAC). So it ends up with an all-or-nothing approach. This works fine if all employees are trustworthy and never make a mistake, but …

When a single contractor is able to inadvertently leak the personal details of all employees in the database, one has to consider whether one person should have the power to do that or if the access should be segregated.

Similarly, if a rogue trader can make investments and harm a bank, one needs to question why systems were set up in a manner that would allow a person to carry out such trades with little oversight. This also goes for allowing developers to accidentally push code to production environments with one click.

Not too long ago a French cinema chain was tricked by an email in a business email compromise (BEC) scam that resulted in the CFO making payments of $21M to the fraudsters. The question shouldn’t be why the CFO allowed was tricked, but rather why did the systems allow the CFO to make such large payments without any checks and balances in place?

While a host of technologies can help in these situations, a bit of forethought with proper separation and accountability can go a long way

Javvad Malik is a London-based IT security professional and was formerly a senior analyst with 451 Research, providing technology vendors, investors and end users with strategic advisory services, including competitive research and go-to-market positioning.

This guest blog is part of a Channel Futures sponsorship.

Read more about:

MSPs
Free Newsletters for the Channel
Register for Your Free Newsletter Now

You May Also Like