After the Okta Breach, Diversify Your Sources of Truth

News that Okta was hacked by the Lapsus$ group in January has caused serious waves in the identity security space.

With the company considered a pillar of security, the confirmed hack of Okta has led many to question the wisdom of being so dependent on their identity manager. Interestingly, many are asking how to move past having a single source of truth for our access control that can also be a single source of failure.

For an industry focused on zero trust, there's a lot of faith put into a couple of security pillars. So what happens when they get knocked? Does the rest of our security infrastructure come crashing down?

Identity at the Center of Security
For many organizations, Okta is the go-to for everything access security when it comes to identity.

These identity providers (IdPs) help organizations manage their identity directories, offer authentication services like single sign-on and multifactor authentication (MFA), and generally make it easier for dealing with the on- and offboarding of employees in the organization.

All great things.

The problem comes when we place way too much trust in any one solution because it can become a single point of failure.

The question becomes: What do you have in place to pick up the baton of security when the first line of defense goes down?

Guarding the Guardians
Even under normal circumstances, we only see the access that we have provisioned ourselves through our IdPs or identity governance and administration (IGA) tools.

If our IdP is compromised, and therefore untrusted, then how are we validating the information that it is providing?

What we need is additional layers of security and visibility. There should be a segregation of duties between the infrastructure that manages our access and the tools that validate that access.

Our tools have to tell us not only what we think we have, but what are really facts in the field that can impact our security.

The way to achieve this is through extensive connectivity with all your organization's apps and services. It is not enough to have visibility in your AWS if your users are also utilizing GitHub, Google Docs, and many other cloud services that businesses depend on for day-to-day work.

We need to see all of the activity happening not only with our identities, but also from the asset side to see which nonfederated (local IAM/external users/service principals) are accessing our assets.

If we can understand how access privileges are being used, then we can pick up on suspicious activity and reduce our exposure with least privilege.

Credentials will be compromised and accounts taken over. Here are three ways we can limit the damage and make it harder for hackers to reach their objectives.

1. Reduce Your Exposure
Avoid those self-inflicted wounds by plugging basic holes in your security. Make sure that every admin user has MFA enabled. It's not perfect, but it is a helpful barrier to make them work harder and can prevent 99.9% of the attacks.

Revoke unused privileges. If an identity has not used a privilege in 30 or 60 days, then they probably do not need it for their day-to-day work.

Perform periodic access reviews where managers and app owners have to approve or revoke access privileges for employees and others. Provide them with the sufficient data to make accurate decisions and avoid rubber stamping. Do these periodically to ensure that everyone has the right baseline level of access.

2. Continuously Monitor For Issues
Once you have a secure baseline of access privileges, you have to continuously monitor that it stays that way.

The way to do it is with policies that can be monitored and alerted on if violations occur. For example if a new admin is created or an access privilege has not been used in 30 days.

Setting enforceable guardrails will enable you to respond quickly and avoid privilege sprawl or risky exposures.

3. Secure Your Supply Chain
Make sure that everyone in your supply chain or other partners are keeping to your standards.

If a mistake or failure to follow best practices on the part of your third party-vendor impacts your customers, it becomes your responsibility to inform them of your expectations and enforce them.

You can pick your metaphor, but a defense-in-depth approach requires that we not put all of our eggs in one product basket or another. Every solution has its limitations and can only play a part in the overall security array.

While authentication and IdP tools are essential first steps, they provide identity and access infrastructure. We need to ask what's happening in the infrastructure and monitor it to become more resilient and ensure that a mistake with a single vendor will not leave us exposed.