The Importance of Defining Credential Types

How many of you have read your access control standard, your compliance standards and then tried to map a set of controls and standards that apply to each account type mentioned? How many have had an incident, and not being sure what type of account is the account in question is, and therefore if the behaviour is actually unusual? Do you have a requirement or policy for shared credentials that do not apply to non-people or visa versa, yet your standard only mentions service accounts?

The first step as an organization, if often to define standards and compliance requirements. Usually, during an engagement, I start by reading these standards. Usually, by the end of the standard, I am horribly confused, and pitty any non-security person trying to make head or tails from such a standard to adhere to the policy. Many times, the same name or term used for multiple account types. Other policies apply to different layers. Like all non-people vs batch. 

Start by looking at your upstream needs, which are usually your compliance requirements. These are the bare minimum. Make sure your frameworks support all your regulatory requirements and that each requirement for each account type is clearly listed against the account type in your framework at the right level. 

Then consider your internal or downstream needs. What attributes does your organization need to track and maintain for each identity type and is creating a grouping by this identity attribute make sense? Is there a standard perhaps you wish your organization to have, to ensure these attributes are available for use? Let's take an example. If you planning on using analytics and UEBA, you probably want to define account types based on algorithms you wish to apply. For example, periodic batch credentials have a very different usage pattern to shared people's credentials. If you were to apply an algorithm or policy in your UEBA software specific to monitor batch credentials for misuse, you will need to know the credential is a batch credential. If you don't have the means to identify batch credentials and use the network to "discover them" how do you know if the account is complaint or not already compromised?

If you find you get too many, create a 3rd layer to the right. For example people, primary, contractors, when a higher layer grouping meets shares a common set of requirements. 

Retroactively collecting attributes is the hardest challenge. Many vendors offer solutions to use the network as the book of record to collect attributes. This uses the network as the book of record and although it will then identify changes to attributes, it assumes that up until that date, the was full trust and no compromise. With a clear control standard, have the business define the account type they need before it is created, and by doing so, define the controls that apply.

Note: I * privileged credentials, since its not the credential, but the access that would be privileged. That said, your control standard probably has some requirement for credentials with privileged access and hence they need to be represented in your framework.