SAP's "Human Error" is No Excuse December 4, 2019

On December 2, 2019, the New Zealand Police announced that their firearms buy-back portal is disclosing sensitive information about gun owners, effectively creating a shopping list for criminals. Software vendor SAP was to blame in this case.

Both SAP and the Police were quick to downplay the severity of this incident:

"We believe this was an isolated incident and made possible due to human error."

"The update was not authorised by Police."

"A new security profile was incorrectly provisioned to a group of 66 dealer users due to human error by SAP."

SAP's "unreserved" apology to the police does not diminish the fact that their security system is unsecure by design. Walking into an unfenced minefield by accident is also human error and an isolated incident, but what prevents the same human error from happening in the future?

How does SAP organize user profiles?

SAP uses a tree structure to describe the hierarchy of roles and sub roles. The following diagram gives an impression of the administrative view:

Beneath the seemingly flexible interface is a web of over-engineered and yet inaccurate complexity. No matter how intricate a group can be described, a user belongs to one or many groups. This is, as SAP calls it, an M:N relationship.

The enforcement of grouping in SAP is symbolic. When the group's access level changes, the user's permissions change accordingly. Imagine at a party where there are regular patrons at different age groups and some are the bar staff. Color-coded labels are worn by each person. The varying access to alcohol is indicated by the label.

Then there is a fire drill and everyone is flushed out to the street. Upon reentry, the labels are reissued. The "unauthorised" SAP update is this fire drill. And even though the correct labels might be correctly, the new rule book now grants so of the more privileged labels the highest level of access. Arms dealers can now see what the police sees.

It is highly likely that only two roles were initially provisioned - the police and regular citizens. When the need to send more pressing notifications to arms dealers arose, a new group was created. During the updating process, the new group was incorrectly mapped to police.

SAP's user authentication can be characterized as

• Group-based
• Symbolically enforced

How would a Gyroscope app manage the users?

A Gyroscope implementation would not have the elements of human error to begin with. Instead of a symbolically enforced group, Gyroscope uses the following structure:

• Capability vectors
• Instantiated user access
• Virtual zoning

Instead of using a "group" to label a user, each user is described with what they can do. Can a person:

• drink?
• pour themselves a drink?
• sell drink to others?
• move beer barrels around?

Also instead of indirectly linking a user to their permissions, the access stays with the user. Having access to the backroom? Here's a key, and the key stays with you. When the access is revoked, the key is also taken away.

But what if the wrong key is handed out because of "human error"? No problem, virtual zoning puts each regular user in its own building - the keys at a wrong location wouldn't work anyway.

With Gyroscope, there are many ways to slice and dice user access. The most suitable design for the firearm buy-back program would be multi-tenancy:Here we have two Gyroscope instances sharing the same database. The police access is not restricted by the virtual container and therefore anyone's record can be seen by the police. Regular users and dealers are in their own bubbles. A dealer can be given optionally more power such as receiving special notifications or even creating new users but every action stays in the same bubble. The worst outcome in the event of a human error is that a dealer wrongly authorizes another user their own information. Any kind of breach would stay inside the container.