Re: Why does PAM exist?

Steven -- Appreciate the follow-up and what you say makes sense.
      

    

    
Given the potential for damage by superuser accounts, it does
      seem like accountability is needed especially there. 

    

    
What happens now seems like this is a case of the "experts" doing
      what they keep others from doing -- sort of like doctors who smoke
      tobacco. 

    

    
I wonder also if part of the problem is that makers of
      infrastructure systems have never been pressed to provide the
      hooks necessary to implement fine-grained access to different
      admin functions, which would make role-based (duties-based) access
      easier for an IAM system to implement. Some (all?) PAM systems
      hack authorization by assigning admin users permissions to run
      specific executables, which has some value. But IAM (ABAC) systems
      like Axiomatics (and perhaps others) implement analogous
      strategies, using query re-write, for example, to limit access
      based on table metadata (cols) or content (cell values).
      Presumably they could do something similar for access to specific
      executables or combinations of executables and parameters. 

    

    
In any case, to your point about over-provisioning of access to
      sysadmins: it seems a good deal of grief could be eliminated in
      sysadmins could be blocked from accessing business data in the
      clear. Presumably, only business types need to see that.   

    

    
In the (little bit of non-hands-on) research I've done on PAM
      offerings one glaring problem seemed to be that the authentication
      required to check out and use the superuser credentials was not
      itself particularly strong, i.e., it was password based. (Reminds
      me of pins protecting soft certs.)

    
As for the bootstrapping issue, I guess you can't have the IAM
      system protect the other systems until somebody installs the IAM
      system. But then that goes for the PAM system, too. 

    

    
At this point I am still inclined to believe that it would be a
      good idea for major "relying parties" (i.e. customers like
      governments and large corporations) to establish a goal being able
      to use one system and one set of policies to control admin-account
      access as well as "user" access to info resources and functions. 

    

    
Again, thanks for the follow-up!

    
Martin

    

    
 

    

    

    

    
On 1/30/2020 5:10 PM, Steven Legg
      wrote:

    

    
      

      Hi Martin,
      

      

      This is an elaboration on my answer to your question during the TC
      conference
      

      call: why does Privileged Access/Account Management exist?
      

      

      IMO, the simple answer is that PAM exists because superuser
      accounts exist.
      

      Superuser accounts tend to be shared accounts used by a number of
      administrators
      

      who all know the password. One problem with this is ensuring that
      only the right
      

      people know the current password as the composition of the group
      of administrators
      

      changes over time. If someone leaves the group then the password
      should be changed
      

      and all the remaining group members informed, but that is easier
      said than done
      

      and often skimped. Another problem is monitoring and auditing what
      individual
      

      administrators are doing. Since they are all using the same login
      credentials we
      

      can't associate any particular action with any particular person.
      

      

      A PAM solution addresses these problems by changing the privileged
      account
      

      password for each session (and keeping it hidden) and recording
      who created the
      

      session and the actions they performed because the administrators
      log in to the
      

      PAM solution as themselves.
      

      

      The shared superuser account is the essential problem. The obvious
      alternative is
      

      to have the administrators authenticate using individual
      identities and to manage
      

      the access controls to give each administrator the access they
      need. When an
      

      administrator leaves, their account can be disabled/removed (by
      another
      

      administrator with the access rights to do so) and, assuming all
      user actions are
      

      recorded, we know who did what when. We still need a way to
      bootstrap the
      

      initial identities and access controls and this is something that
      a superuser
      

      account has traditionally been used for. However, there has been a
      tendency to
      

      attach all sorts of administrative activities with the superuser
      account, to the
      

      extent that some administrative actions can only be performed by
      the superuser
      

      account. A reason applications might do this is to avoid having to
      address
      

      managing access rights for administrative activities.
      

      

      So inadequate or non-existent support for managing access rights
      for
      

      administrative actions forces administrative users to use a common
      superuser
      

      account and, consequently, PAM is a thing. At least, that's the
      way I see it.
      

      

      Regards,
      

      Steven
      

    
    
-- 

      Martin F Smith

      BFC Consulting, LLC

      McLean, VA

      703 389-3224 mobile