Did the SEC Forever Change Security?

Okta Breach - How Were They Hacked?

Okta wrapped up its investigation into its most recent breach. They dropped a blog post laying it all out. Don’t worry, I’ve got you covered with the details. Here’s what happened…

Initial Compromise

Using an Okta company managed device, an Okta employee logged into Chrome with their personal Google account.

That employee then accidentally saved credentials for an Okta support system service account to their personal Google Password Manager.

That service account had permission to view and update customer support tickets in the system.

And then an attacker got access to those credentials…

Okta rightly noted that the most likely scenario for an attacker getting those credentials was through the compromise of the Okta employee’s personal Google account or device. It’s well known that infostealers target credentials stored in the Chrome browser.

Unauthorized Access to The Support System

Between September 28, 2023 and October 17, 2023, the attacker used the stolen service account credentials to access Okta’s customer support system.

During that time, the attacker accessed files tied to 134 Okta customers (which is less than 1% of Okta customers). A subset of those files were the now infamous HAR files that contained session cookies for Okta’s customers.

Of those 134 Okta customers, the threat actor hijacked session cookies for five Okta customers. Three of which we already know to be 1Password, Cloudflare, and BeyondTrust. The other two we may never know.

Containment and Remediation

Okta took the following steps to kick the attacker out and strengthen the environment:

1. Disabled the compromised service account.

2. Blocked the use of personal Google profiles in Google Chrome on Okta-managed devices.

3. Improved detection capabilities for the customer support system.

4. Implemented session token binding for Okta administrator accounts.

That last one is my personal favorite. It protects against the theft of session cookies. It works by binding the session cookie to the network location (specifically by ASN) from which the legitimate logon originated.

So if the legitimate admin logs in from NYC and an attacker steals the session cookie and logs in from Boston, it would force the user to re-authenticate using MFA (which presumably the attacker doesn’t have).

That’s a huge win. Make sure you implement that in your environment.

Additional reading
Okta’s Security Incident Writeup

The SEC Drops the Gauntlet

This week, the SEC filed charges against SolarWinds and their CISO for defrauding investors about the state of their security program.

I’ll be honest…my initial reaction to the news was “how could the SEC do that!?” Initial reactions of CISO peers and security experts ranged from similar shock to others calling this a watershed moment that gives CISOs a “holy hand grenade” to implement change.

It took me some time to formulate my own position. I looked at various news articles, opinions of others, and most importantly, I read the full 68-page complaint myself.

That complaint is what solidified my feelings, which was counter to my initial reaction…but it’s complicated…

The SEC Complaint

The SEC’s core issue is that public statements that SolarWinds and their CISO made about their security controls did not match what was actually in place.

The SEC complaint stated that SolarWinds and its then-Vice President of Security and Architecture, Tim Brown:

I found three core issues the SEC laid out in their compliant. I’ll lay them out here.

Issue #1: Public Statements on Security Controls vs Internal Knowledge

The SEC claims that SolarWinds and their CISO reported publicly about the state of their security controls and practices:

1. Compliant with the NIST Framework

2. Used a secure development lifecycle

3. Had strong password protection

4. Maintained good access controls

Through the SEC’s investigation of internal communications, they found that SolarWinds and their CISO “knew, or was reckless or negligent in not knowing” that the controls they stated publicly that they had implemented were in fact not implemented. Most importantly, the SEC is stating that SolarWinds and their CISO knew they did not exist but made no attempt to update their public statements.

Issue #2: SolarWinds Failed to Raise Concerns over Security Issues

The SEC went further on the allegations that SolarWinds and their CISO knew their public statements were not accurate. The SEC stated:

The SEC is essentially saying that even though SolarWinds and the CISO knew that what they were saying publicly about their security program was wrong, they made no attempt to correct it in their public filings.

Said another way, even as they learned more about the state of their security, they made no attempt to update their original statements around their risks.

Issue #3: Misleading Statements in their 8-K

Lastly, after the now infamous SUNBURST incident was “officially” discovered and reported in an 8-K, it still did not include the relevant information known at that time. As a reminder, the SUNBURST incident was when a Russian state-sponsored attacker modified SolarWind’s source code to contain a backdoor. The attackers used that backdoor to access SolarWind customers’ environments in a supply chain attack.

The SEC stated:

Here the SEC is saying that SolarWinds and their CISO knowingly withheld information that attackers were actively using their access to SolarWinds to compromise SolarWinds’ clients, which misrepresented the alleged known state at that time.

So This is Good?

In one aspect, yes. The SEC made it crystal clear that companies need to have strong controls that are specific to the risks the organization faces. And further, if you know what those risks are, you have to inform investors about said risks.’

Further, the SEC said that understaffing and a backlog of security issues should have been a red flag to SolarWinds leadership that additional resources were required to manage the risk.

These are positive in that there is strong language that organizations:

1. Need to be serious about investing in security controls

2. Need to be transparent in what they know about the state of their security controls and potential cyber risks

So it’s Bad Then?

There are unintended consequences that will come from this. Too many to list. But a key one is the personal liability that now exists for CISOs.

While many have made comparisons to CEOs and CFOs being personally liable for fraud, it’s just not the same.

The nuance is that CEOs and CFOs have the authority to shift behavior in an organization. They can operate with a hammer when needed.

Those tools don’t exist for CISOs yet. CISOs don’t have the ability to wave a magic wand and get the rest of the company to implement the required security controls - even super critcial ones.

Where Do We Go From Here?

For any CISO, your job remains the same. Identify, inform, and mitigate on security risks in your organization.

The SEC has made it clear that companies need to step up to fix security gaps and inform the public of what those gaps are. This is something that can and should be used to your advantage where possible.

But the reality is that it’s not a silver bullet for a security leader to implement the change that needs to happen.

A security leader cannot and should not operate in an environment where they can’t get the buy-in for implementing their security program. This goes doubly if they are pressured to misrepresent the state of security controls. That’s a nonstarter and time to exit.

We’re in an interesting time with the SEC’s actions. While there is some good that could come from it, I fear that there are far more unintended negative consequences that will arise in the coming years.

That was a lot of information and it only scratches the surface of the thoughts I have. Thanks for sticking with me this far.

As for where we go from here? Stay tuned…it’s going to be an interesting time.

Additional Reading
SEC Press Release
SEC Complaint