What the Auth?

  • 19 September 2023
  • 2 replies
  • 51 views
D
Rank
Userlevel 2

In the threat modelling methodology I use, I ask teams to capture the authentication and authorization methods that the different parts of their system implement (for those bits in-scope).  This ask, as it turns out, has been something that teams have really struggled with.  It seems to be a combination of not always having the difference between authn and authz very clear in their mind, and the fact that sometimes the difference is indeed not very clear at all anyway! (IP allow-lists is a good example - authn or authz? or it depends?).

In an effort to at least bring some consistency in how the teams I work with capture authn and authz, I created some Examples and some Guidance to help them, which I thought I would share, in case it helps others as well.

If you know of any authn/z guidance, examples or docs that might help others, please do share.

2 replies

JamesR
Rank
Userlevel 3
Badge

I would consider IP allow list an authentication mechanism since it would fit into “somewhere I am” which is a factor of authentication. 

I like the examples you created.  Would it be helpful to also pair the authentication column with which factor of authentication they intersect with? Might reinforce the authentication function and then everything is just authorization. 

Do you define anything in terms of policy enforcement point vs policy decision point for threat modeling zero trust? As I was trying to come up with examples I kept coming back to hotels with multiple key card access levels. Access to the lobby vs Access to a floor vs Access to the room vs Access to the kitchen etc. Of course in that example, we have authentication as an approved user to get into the hotel and then everything else is just authorization and policy enforcement points. 

 

James Rabe
D
Rank
Userlevel 2

For the sake of discussion, I would say for an IP allowlist, “it depends”.  This is because when I think of authentication I think it involves establishing the identity of the caller by mapping the claimed identity to a registered identity in an identity directory (be that LDAP or a local file or whatever).  This is not the only (or perhaps even the best) way to think about authn, but in my experience it makes it easier to be consistent.

So if the IP allowlist is for a /16 range then that’s not a registered identity of an individual, so in that case I call it authz. If the allowlist is a specific /32 IP, then that is more likely authn.

Which all really goes to re-enforce the point of my post, that differentiating authn and authz can be a challenge, even for security folk, so the teams we work with need all the help we can offer.

With regards to factors of authentication - I try to get teams to populate the authn/authz information, so I wouldn’t want them to provide this extra information unless I thought it routinely would offer value, which in my experience, would only be the case when multiple factors are in use, which normally only applies to users, and not different parts of a system.  I would still capture these factors (when relevant) as Controls though.

With regards to PEPs/PDPs - they are a great way to think about the access control implemented within a system.  Unfortunately the devs I have worked with probably wouldn’t be very familiar with these concepts, and think more in terms of permissions, scopes and roles etc, as this is the terminology of the technology they use.  To make TMing as easy as possible for them, I just let them use the terms they are familiar with.  Still, for security folk, thinking in terms of PEPs/PDPs is a great way to model access control in a system.

Reply


Terms and Conditions, Community Guidelines and Privacy.Cookie settings
V2