Understanding Enterprise

Identity
The Three Pillars of Cybersecurity

• Identity – The protection of a user’s

identity, account, and credentials from
inappropriate access
• Privilege – The protection of the
rights, privileges, and access control
for an identity or account
• Asset – The protection of a resource
used by an identity, directly or as a
service
mitigating threats
• Zero trust is a security model based on the principle of maintaining
strict access controls and not trusting anyone, anywhere, at any time,
even those already inside the network perimeter, by default.
• Just-in-time privileged access is a strategy that aligns real-time
requests for usage of privileged accounts directly with entitlements,
workflow, and appropriate access policies.
Credentials
• A credential is an account with an associated password, passcode,
certificate, or other types of key.
• Credentials can have more than one security mechanism assigned to them –
this is called dual or multifactor authentication.
• Credentials can also be shared and used anonymously. In the case of an
anonymous account, the credentials use a null password. This is different
than a guest account.
• Credentials are simply the representation of the account and authentication
secret combination used for authentication.
• When someone has “hacked” an account, what it really means is that they
have taken over control of the credentials associated with the account.
Accounts
• An account is an electronic representation of an identity and can have a
one-to-many relationship with the identity. One identity can, therefore,
have multiple accounts.
• These accounts reference a set of permissions and privileges needed for an
application or asset to connect or operate within the confines of a resource.
• Accounts can have complex relationships with identities and can be defined
locally, grouped together, nested in groups, or managed via identity
infrastructure such as directory services.
• Excessive assignment of privileges to any given account goes against the
principle of least privilege and will greatly increase cyber risk and the
potential for a privileged attack vector.
Types of Accounts
• Identities can be assigned a wide variety of accounts across the
enterprise. Accounts can be of many different types and use a wide
variety of techniques to enforce credentials, control entitlement, and
govern access.
• If a single account is compromised, it can be used to compromise the
entire identity and all of its privileges.
• For instance, the compromise of an account with administrator
access, or some other high-level application privilege, can easily be
leveraged against the identity to compromise other associated
accounts and services.
• To reduce the likelihood and impact of attacks that abuse or escalate
privileges, we should always strive to restrict the assignment of
privileges to the lowest common denominator for every type of
account.
• This concept is called least privilege and should, whenever possible,
be implemented on all account types to help avoid an account-level
attack from escalating back to the identity itself.
Local Accounts
• Local accounts are just that, local to the resource or asset. They may, or
may not, be centrally managed or referenced in an identity
management solution.
• Duplicate accounts with the same credentials often exist across similar
assets and should be discovered, cataloged, and managed in order to
govern their access. If duplicate local accounts do exist and they are
using the same passwords, the system is likely exposed to significant
privileged attack vectors and lateral movement.
• If the duplicate local accounts do have high-level privileged access, a
compromise of the credentials could lead to the complete compromise
of the asset.
• Example: IoT coffee maker, which has a local administrative account
built into its management software called “admin.” Changing the
username may not be possible, but if there is more than one coffee
maker within your organization, each should have a unique password.
Managing those passwords is a very well-understood problem and
can be addressed using a Privileged Access Management (PAM)
solution.
Centralized Accounts
• Centralized accounts are typically stored in a directory service like
Microsoft’s Active Directory (AD) or a generic Lightweight Directory
Access Protocol (LDAP) implementation.
• These are commonly referred to as directory-based accounts. The
benefit of centralized accounts is that they allow for a single point of
management for all of the subscribing resources that must
authenticate against a given account.
• Centralized accounts allow users to login into various resources
throughout an enterprise and provide access to assets and data in
order to perform authorized tasks.
• if the account compromised is a directory service administrator, or
worse a directory-domain administrator, then not only is that user at
risk but every other account stored in that directory infrastructure.
• Proper mitigation activities would require reloading the entire
environment from scratch! Therefore, environments should always
protect domain administrator accounts with the highest level of
security possible. This should include strong authentication based on
multifactor, two-factor, or step-up authentication techniques
whenever possible.
Functional Accounts
• Functional accounts are accounts used to perform automated account
management functions. They can be local or centralized, but always have
elevated access rights, often domain administrator or root privileges
across multiple resources and assets.
• Functional accounts should always be owned by an identity for control
and audit purposes, but they should be strictly used for automation
purposes and never be used for any daily work tasks.
• Example: coffee maker scenario, a functional account would manage all
of the accounts of each and every IoT coffee maker. This functional
account would then be under the strict control of an Identity Governance
solution and its passwords potentially managed inside the PAM solution.
Managed or Proxy Accounts
• Managed, or what are often referred to as proxy, accounts have a
relationship to functional accounts in that the credentials, or their creation
and revocation, are managed by a functional account.
• Managed accounts can be associated with identities, or they can be strictly
electronic in nature. It all depends on the use case.
• The account is not directly managed by an identity – it is managed through
another account type.
• This distinction can help shield the identity from flaws that would result in
duplicate credentials, stale or weak passwords, and other authentication
problems that could lead to a compromised identity.
• This also includes accounts for former employees and contractors that
should be disabled or removed.
Service Accounts
• A service account is a special type of local or central account that is created
explicitly to provide permissions and privileges operating under an
administrative context within the operating system or its supporting
infrastructure.
• The permissions and privileges assigned determine the service account’s ability
to access local and network resources during its runtime.
• The reason service accounts are a special type of account is because they
should not have the same characteristics as a person logging on to a system.
They should not have interactive user interface privileges nor the capabilities to
operate as a normal account or user.
• Service accounts should also not be delegated to any form of just-in-time
provisioning model either.
Application Management Accounts
• Application management accounts should not be confused with service
accounts. Service accounts provide the runtime credentials required for
an application to execute, while application management accounts
provide credentials used for applications to interoperate.
• These accounts are typically referenced in the industry as application-to-
application accounts (A2A)
• As another rule of thumb, identities should not be directly associated
with these application accounts either.
• Application accounts must therefore be managed such that any changes
to the shared credentials are synchronized between the applications
themselves before they are required for authentication.
• If a threat actor compromises an application management account,
they can impersonate the runtime communications between
applications and potentially monitor activity. This can happen by
spoofing the authentication process using a man in the middle attack.
This has been seen in some of the most famous bank fraud breaches
that have been perpetrated over the last few years.
Cloud Accounts
• There technically is no accepted definition and terminology to explain
cloud accounts. Each cloud provider – Software as a Service (SaaS)
vendor, Platform as a Service (PaaS) vendor, and Infrastructure as a
Service (IaaS) vendor – uses a different definition to meet their
business and technology approaches to solutions and management in
the cloud.
• the use of cloud accounts is strictly a vehicle to describe any account
in the cloud that is under control of an organization. These accounts
may, or may not, have an identity assigned and may or may not have
functional, application, or managed account characteristics.
• The point of highlighting this account type is that you do not own the
environment you are operating in – it is a shared cloud resource. Cloud
accounts can have privileges assigned to them, and they may (or may
not) support the principles of identity.
• compromised in two ways, unlike with an on-premise solution: first
from the front – that is, all of your cloud account-based access – and
second from the back, everything owned by the cloud provider,
including their accounts used to support and manage the service.
• The latter dynamic is why special considerations need to be made for
accounts in the cloud, particularly if they are linked in any way to other
identities.