role based site security - the nuclear missile condition

Question

So I'm in the process of working on part of our new role based site security system and have come up to the "nuclear missile" condition.

The system is based around the idea of grouping, with the ability for users to be implied to be in groups based on current groups, like so:

• Tom is a master Cake Maker

• by putting him in the Cake Maker group, it also implies that he is in the baker group, thus he doesn't need to be physically put in that group.

• By implication of being in the baker group, he could be put into any other baking sub group.

• If tom became CEO of his bakery, he would be taken out of the baking group and be put in the CEO group, which then implies he has access to all groups (baking, cake making, etc).

The "nuclear missile" condition is thus: I am a web developer, thus i need to have access to all groups so i can test for various conditions and bugs that may occur during the lifecycle. But there also might be sensitive data that I shouldn't be looking at, this might belong to the HR group or the Finance group. By implementing the nuclear missile system it would mean for me to get access to the live pages, someone from the HR group or Finance group would have to provide their password at the same time as mine.. 2 password fields on a page.

This is quite a fun solution, but i'm not convinced altogether practical. How do you generally protect rogue system developers against sensitive data? do you hash anything sensitive and only reveal if the person is actually a member of the group that belongs to the data.

do you even care?

Answer 1

A similar solution is used for emergency cases, often called a 'break-glass' solution and it typically requires a separate administrator level account, with a password split into two halves, and documentation on these passwords held in safes (usually IT's and an executive safe)

I don't think your use case qualifies as emergency, as it could happen pretty often, so what you find is much more common are controls implemented at the personnel level, including:

• more stringent vetting
• logging of everything privileged users do

This allows work to carry on as normal without being impacted by intrusive security controls, while also protecting the company.

Of course the above holds for developers with access to live. For developers running BAU tasks, the preferred method is for them to only have sanitised data. They would take the customer account database, generate replacement names and addresses and use these in Dev, UAT, OAT and Pre-Prod environments so Devs never got access to the live environment.

Over the last 16 years I can probably count the number of organisations that do that on the fingers of one hand, so go back up and use vetting and logging. Sorry, but that's the way it tends to work.

Answer 2

The solution I most encountered consisted in a single layer of groups, and as such no group inheritance. The problem arises when a person belongs to two or more groups with conflicting rights. Then you have the choice to either go one way (example: granted access > denied access) or the opposite way.

This is I think the most easier way because otherwise you may run into trouble with group inheritance (and I suspect you would have to provide a complex interface for mamaging user groups, right?)

Now, one thing struck me in your question:

But there also might be sensitive data that I shouldn't be looking at, this might belong to the HR group or the Finance group

Regardless of your solution, you should work on anonymized data, not on real data. If you are working on an exact copy of a production database the first step for you or (if you are lucky to have one) for your database administrator to provide you with an anonymized copy of the database. Numbers may be randomized, names too (there are name databases available online for free), etc.

That way, you are not to worry in which group you are, you may be in all possible groups, or in a super group inheriting from all groups, you can safely test your web application knowing it will not be possible to learn how much your boss is paid ;-)