Page 47 - Cyber Defense eMagazine Annual RSA Edition for 2024

Building such an architecture from the ground up – not to mention in an existing organization – is no small
feat. How can you convince the board of a company to invest or even put some of the business continuity
at risk, because an app in tier2 has too much access on tier1, and now this needs to be revoked,
reprogrammed, retested etc.?

If building it yourself is too hard, you may think existing security solutions can solve this for you, but you
would be wrong. Unfortunately, security solutions today mostly focus on two things:

• Visibility: showing customers issues in their directory configuration, and maybe highlight several
paths to solutions.
• Access Management: Protecting privileged identities from leaking by using credential vaults and
privileged access gateways.

Even when combined, neither of these approaches solve the problem. Even with enough visibility, the
solution can be too complex or painful. And even with enough access management you can’t deploy this
solution to the entire organization, only a small subset of identities. The reality is that there are a lot of
overlaps between tiers, which leaves a gap that can be exploited.

Segmenting Identities

The task of managing identities can be overwhelming for anyone. Instead of trying to manage access
and privileges, we propose a novel approach: identity segmentation. Put simply, it means that identities
are first classified into their respective tiers, and then segmented so that they don’t leak to lower-level
tiers.

Classification is definitely not trivial. This post by SpecterOps does a great job of showing some methods
(using open-source tools) of identifying tier0 accounts and assets. In this phase, we can identify the
privileged accounts that are tier0, which assets they log onto (which are also tier0 assets), identify
services accounts and their servers as tier1, and the rest of the accounts which are tier2.

The next phase is segmentation; this is the ability to deny logon operations of an account based on a
set of rules. Normally, we want to prevent accounts from one tier to perform logons to other tiers as this
exposes these accounts to potential leak. These preventions go both ways, as we don’t want a privileged
account logging onto a lower privileged asset or a regular user logging onto a higher tiered asset where
they could compromise a more privileged account.

We can even segment identities further in the same tier. For example, by limiting service accounts from
performing abnormal types of logons, as this may be used for lateral movement in the same tier.

47