Speaker 1: Okay, so start with a mental image. Let's say you're
Speaker 1: the guardian of a castle, right, I mean, in the
Speaker 1: medieval model, security was incredibly straightforward. You had thick stone walls,
Speaker 1: a deep moat.
Speaker 2: A heavy drawbridge. Yeah, that's the classic perimeter defense. It's comforting,
Speaker 2: it's visible, and in the.
Speaker 1: Modern world it's completely obsolete, totally absolute, right because the
Speaker 1: castle has well, it's effectively exploded. The treasury is in
Speaker 1: a public cloud, your armory is on an employee's personal
Speaker 1: iPhone at a coffee shop.
Speaker 2: And the throne room is a zoom call exactly.
Speaker 1: So the question we're tackling today is how do you
Speaker 1: hand out keys to a castle that's everywhere and nowhere
Speaker 1: at the same time.
Speaker 2: That is the fundamental paradox of the modern workplace, and
Speaker 2: it's exactly why we're taking a deep dive into OCTA
Speaker 2: Administration up and running. This isn't just about software, it's
Speaker 2: really about the architecture of trust, and.
Speaker 1: This book it really feels like a manual for that
Speaker 1: exact shift. It's moving us from securing the network to
Speaker 1: secure the identity. They're basically arguing that Identity Access Management
Speaker 1: IAM is the new perimeter.
Speaker 2: It has to be.
Speaker 1: But before we get into the heavy technical lifting, and
Speaker 1: we will, we have to talk about the name. I've
Speaker 1: used Octa. I've seen the logo, but I honestly just
Speaker 1: thought it was a made up tet word A lot
Speaker 1: of people do.
Speaker 2: But there's a great bit of trivia there that actually
Speaker 2: explains their whole business model. Okay, So the founders, Tom
Speaker 2: McKinnon and Frederick Karras, they both came out of Salesforce
Speaker 2: and back in two thousand and eight, right in the
Speaker 2: middle of the recession, they made this huge bet that
Speaker 2: the cloud wasn't just for giants but for everyone.
Speaker 1: And the name okta, that's not random, not at all.
Speaker 2: It actually comes from meteorology.
Speaker 1: Meteorology, Yeah, cloud cover.
Speaker 2: Is measured in units called oktas. It's a scale that
Speaker 2: goes from zero to eight. Zero okdas is a completely
Speaker 2: clear blue.
Speaker 1: Sky, and eight octas would be eight octas.
Speaker 2: Is completely overcast total cloud cover.
Speaker 1: So the company's entire mission is hidden right there in
Speaker 1: the name. They want to provide total cover for all
Speaker 1: cloud access.
Speaker 2: That's actually pretty clever and it connects directly to their strategy.
Speaker 2: The book describes Octa as the Switzerland of identity.
Speaker 1: I like that analogy because when you think about the
Speaker 1: big players like Microsoft, Google, Oracle, they all have identity solutions.
Speaker 1: Microsoft has untri id, Google has its own thing, but
Speaker 1: they also have these massive ecosystems they want to lock
Speaker 1: you into.
Speaker 2: Precisely, Microsoft wants you an Azure but Octa. They don't
Speaker 2: have an email server or a cloud storage platform to
Speaker 2: sell you. They are purely the identity layer. They're the broker,
Speaker 2: so they're neutral ground, right. They have over sixty five
Speaker 2: hundred pre built integrations. They don't care if you use
Speaker 2: Aws or Azure, slacker teams. Their only job is to
Speaker 2: connect them, and that neutrality is a huge competitive advantage.
Speaker 1: Okay, so that's the who. Let's get into the how.
Speaker 1: The book leans so heavily on this idea of zero trust. Now,
Speaker 1: to me, that phrase zero trust, it sounds like a
Speaker 1: bad relationship. Trust no one.
Speaker 2: It is cynical, but it's a necessary cynicism. The old
Speaker 2: castle model assumed that if you were inside the firewall,
Speaker 2: you know, you plugged an Ethernet cable into the wall
Speaker 2: of the office, you were trusted by default, You're one
Speaker 2: of the good guys.
Speaker 1: Right.
Speaker 2: Zero trust just flips that completely says never trust, always verify.
Speaker 1: So even if I'm the CEO in the headquarters building
Speaker 1: plugged into the wall.
Speaker 2: Doesn't matter. The system verifies you, your device and your
Speaker 2: context every single time. And the book breaks this down
Speaker 2: into a maturity model because you don't just, you know,
Speaker 2: flip a switch and become zero trust overnight.
Speaker 1: I think a lot of people are going to recognize
Speaker 1: their own companies in these stages. Let's walk through them.
Speaker 2: Sure. Stage zero is fragmented identity. This is the legacy world.
Speaker 2: You've got on premise, active directory, firewalls, VPNs, and.
Speaker 1: A sticky note on your monitor with five different passwords
Speaker 1: for five different.
Speaker 2: Sites, the sticky note of doom exactly. Then you move
Speaker 2: to stage one, unified. I am this is where life
Speaker 2: gets better. You introduce a single finn on.
Speaker 1: As SSO one log in for everything.
Speaker 2: And you start using basic multifactor authentication MFA. That's the
Speaker 2: code on your phone, the push notification.
Speaker 1: Okay, that's pretty standard now it is.
Speaker 2: But stage two is where it gets really interesting. Contextual access.
Speaker 2: The system stops just looking at who you are. It
Speaker 2: starts looking at where you are and what you're using.
Speaker 1: Give me an example of context okay.
Speaker 2: So you log in every day from London on your
Speaker 2: corporate laptop. Suddenly your credentials pop up from North Korea
Speaker 2: at three am on some random iPad.
Speaker 1: Right.
Speaker 2: Stage one security might let that through if the hacker
Speaker 2: has your password. Stage two, contextual access says, wait a minute,
Speaker 2: the context is all wrong. Block it.
Speaker 1: It's spotting the anomalies. So what's stage three?
Speaker 2: Stage three is the adaptive workforce. This is high level automation.
Speaker 2: Your security tools are all talking to each other. So,
Speaker 2: for example, if your endpoint protection software finds a virus on.
Speaker 1: Your laptop, CrowdStrike or something.
Speaker 2: Yeah, exactly, it sends a signal to Octa automatically, and
Speaker 2: Octa instantly revokes your access to salesforce to slack to everything.
Speaker 1: So the laptop basically snitches on itself to the identity provider.
Speaker 2: Yes, no human has to wake up at two in
Speaker 2: the morning to click a button. The system just heals itself.
Speaker 1: That sounds like the dream. But to build any of
Speaker 1: that you need a really solid foundation. The book spends
Speaker 1: a ton of time on something called the universal directory.
Speaker 2: It's the single source of truth. In most companies, user
Speaker 2: data is just a mess. You've got records in an
Speaker 2: HR system, logins an active directory, email accounts somewhere else,
Speaker 2: Universal directory or UD pulls all that together into one unified.
Speaker 1: View, but they don't all come from the same place.
Speaker 1: The book lists three user types, which seems like a
Speaker 1: really important distinction oly critical.
Speaker 2: First, you have octamastered users. These are people you create
Speaker 2: right inside the OCTA admin console.
Speaker 1: So that could be like a contractor who doesn't need
Speaker 1: to be in the main HR system exactly.
Speaker 2: Second, directory master users imported from a server like active directory.
Speaker 2: And third application mastered these users come from an app
Speaker 2: like Workday or Salesforce.
Speaker 1: And why does it matter so much where the user lives.
Speaker 2: Because it determines who has the power to change the data.
Speaker 2: If a user is directory mastered, you can't change their
Speaker 2: password inside Octa. You have to change it on the server.
Speaker 2: It prevents these data conflicts.
Speaker 1: Hight, and that leads to this concept I found really
Speaker 1: interesting in the book, a tribute level mastering.
Speaker 2: Yes, it's like building a Frankenstein's Monster of a user profile,
Speaker 2: but in a good way. Okay, you can tell ACTA, Okay,
Speaker 2: I want the user's job title to come from the
Speaker 2: HR system because that's official. But the office phone number,
Speaker 2: pull that from active directory, and let the user update
Speaker 2: their own secondary email for password recovery.
Speaker 1: So OCTA sits in the middle playing traffic cup, grabbing
Speaker 1: different bits of info from different places, and then presents
Speaker 1: one complete profile to all the other apps.
Speaker 2: Exactly. It solves that data fragmentation problem. And once you
Speaker 2: have that data flowing, you can enable something called just
Speaker 2: in time provisioning or jiit JIT.
Speaker 1: It's in manufacturing.
Speaker 2: Kind of imagine a new employee starts instead of an
Speaker 2: admin manually creating an account, JIT creates at the very
Speaker 2: first time they try to log in ocases they have
Speaker 2: valid credentials from say active directory, and says, oh, you
Speaker 2: don't have an account here yet, let me build one
Speaker 2: for you right now.
Speaker 1: And that gets rid of the bottleneck where new hires
Speaker 1: are just sitting around for days waiting for access.
Speaker 2: Precisely, it keeps the directory fresh without all the manual work.
Speaker 1: That's efficiency. Let's talk about managing all these users. You
Speaker 1: can't do it one by one. You need groups. And
Speaker 1: the authors put a huge warning label on one specific group,
Speaker 1: the everyone group. It sounds so harmless, so inclusive. Why
Speaker 1: is it a trap?
Speaker 2: Because it's hard coded. Every single user account in your
Speaker 2: system is automatically in the Everyone group. You can't rename it,
Speaker 2: you can't delete it. The trap is when a lazy
Speaker 2: admin assigns a sensitive app to.
Speaker 1: That group, because then everyone gets access.
Speaker 2: Everyone, the CEO, the summer intern, the external contractor. Oh wow.
Speaker 2: So if you assign the corporate credit card portal to
Speaker 2: the Everyone group, you've just given a credit card to
Speaker 2: your external vendors. It's a disaster waiting to happen.
Speaker 1: So the advice is basically, just don't touch it for
Speaker 1: anything important, Treat.
Speaker 2: It with extreme caution, use it for low risk things, sure,
Speaker 2: but never for anything sensitive. And the authors give a
Speaker 2: great little life hack here for naming your other groups.
Speaker 1: I loved this tip.
Speaker 2: It's so simple it is. It's because octagroups don't have
Speaker 2: folders or any kind of hierarchy. It's just one long, flat,
Speaker 2: alphabetical list. The tip is to use numbers to force a.
Speaker 1: Structure, so like zero zero dot all employees, or something exactly.
Speaker 2: Zero zero dot organization, zero one sales, zero two dot marketing.
Speaker 2: By putting a number at the front, you force the
Speaker 2: list to sort. Logically, you're basically mimicking a folder structure
Speaker 2: where one doesn't exist.
Speaker 1: That is one of those tips that only comes from
Speaker 1: someone who's actually been in the trenches for sure. Now
Speaker 1: what about push groups? That sound a powerful but also
Speaker 1: a little risky.
Speaker 2: They are so normally you import groups from an app.
Speaker 2: Push groups. Let you take an Octa group and force
Speaker 2: it into an app like Slack or Box.
Speaker 1: So I create a sales group in Octa and poof,
Speaker 1: a sales channel appears in Slack.
Speaker 2: Yes, but the risk is the sink Octa is the boss.
Speaker 2: If you go into Slack and rename that channel to
Speaker 2: global Sales, Octa doesn't know you did that, the link breaks,
Speaker 2: or worse, Octa sees the name is wrong. It just
Speaker 2: pushes a new sales group. Now you have duplicates.
Speaker 1: So the rule is if OCTA's pushing the group, don't
Speaker 1: touch it anywhere else.
Speaker 2: You have to respect the source of truth.
Speaker 1: We've been talking a lot about the cloud, but the
Speaker 1: book is realistic. Most companies are still hybrid. They've still
Speaker 1: got that server room with active directory running.
Speaker 2: The hybrid reality. Yeah, companies have twenty years of history
Speaker 2: baked into active directory. You can't just rip that out.
Speaker 2: So Octa uses agents.
Speaker 1: Not secret agents.
Speaker 2: No software agents, little services you install on your internal
Speaker 2: servers that act as a bridge. The AD agent sits
Speaker 2: behind your firewall and talks to the Octa cloud.
Speaker 1: But doesn't that mean punching a hole in your firewall?
Speaker 1: Security teams hate that.
Speaker 2: That's the beauty of it. No inbound ports are required.
Speaker 2: The agent makes an outbound call to Octa over standard HTTPS.
Speaker 2: It phones home. It's very secure.
Speaker 1: And there's one feature that uses these agents that sounds
Speaker 1: almost like magic for the user.
Speaker 2: Desktop sso Desktop Single sign on. It's a seamless experience.
Speaker 2: If you're at the office, you log into your Windows
Speaker 2: PC and the agent basically vouches for you. When you
Speaker 2: open a browser to go to Octa, you don't have
Speaker 2: to type your.
Speaker 1: Password again because the computer already knows who you are.
Speaker 2: That's it exactly uses IWA Integrated Windows Authentication. It passes
Speaker 2: a cerbero's ticket in the background. It removes friction, and insecurity,
Speaker 2: friction is the enemy.
Speaker 1: If you make it too hard, people use sticky notes, right.
Speaker 2: If you make it invisible, they'll comply.
Speaker 1: So speaking of friction, let's get into policies. This is
Speaker 1: the logic layer. The book really stresses that the order
Speaker 1: of your policies matters.
Speaker 2: This is probably the most commonplace admins make mistakes. Evaluates
Speaker 2: policies in a top down numerical order. Think of a
Speaker 2: bouncer with a checklist. Okay, he reads rule number one,
Speaker 2: does it apply to you? If yes, he does what
Speaker 2: it says, and then he stops reading.
Speaker 1: He doesn't even check rule number two.
Speaker 2: It never gets to rule two. So if you put
Speaker 2: a really broad rule at the top that says allow everyone,
Speaker 2: and a strict rule at the bottom that says block hackers.
Speaker 1: The hackers are getting in because they matched rule number
Speaker 1: one first exactly.
Speaker 2: You have to structure your policies like a funnel. Specific
Speaker 2: restrictive rules go at the top, the broad cash all
Speaker 2: rules go at the very bottom.
Speaker 1: And you apply this logic to what password policies and
Speaker 1: sign on policies.
Speaker 2: Those are the two main ones. Password policies are what
Speaker 2: you'd expect, you know, length, complexity. But the book mentions
Speaker 2: password history, which is important.
Speaker 1: To stop people from just changing the number at the
Speaker 1: end of their password.
Speaker 2: It stops the winter twenty twenty three then Spring twenty
Speaker 2: twenty three cycle. You can tell octat to remember the
Speaker 2: last four or five passwords and forbid the user from
Speaker 2: reusing them.
Speaker 1: And sign on policies. That's about access.
Speaker 2: That's about access. This is where you grade the log
Speaker 2: in attempt. You set up risk factors. Is the user
Speaker 2: on a managed device? Are they coming from a known
Speaker 2: corporate IP address?
Speaker 1: And based on that you make a decision.
Speaker 2: Right, And the decision isn't just allow or deny. The
Speaker 2: most powerful one is prompt for factor.
Speaker 1: So ask for the MFA code.
Speaker 2: Correct. If you're in the office on a corporate laptop,
Speaker 2: maybe we trust you enough, no code needed. If you're
Speaker 2: at Starbucks on your personal phone, we don't trust the network.
Speaker 2: Prompt for the code. That's contextual access in action.
Speaker 1: It all connects back to that zero trust idea. It's
Speaker 1: not a simple yes or no.
Speaker 2: It's a sliding scale of trust.
Speaker 1: I want to circle back to one thing about importing users.
Speaker 1: The book mentions import safeguards. This sounded like a panic
Speaker 1: button for admins.
Speaker 2: It's more of a don't get fired button.
Speaker 1: Yeah.
Speaker 2: Imagine you mess up a query and active directory and
Speaker 2: suddenly it looks like you just deleted five hundred users.
Speaker 2: Oh no, if OXTA sinks that change, it would deactivate
Speaker 2: five hundred accounts instantly, Half the companies locked out. The
Speaker 2: help desk phones would literally melt chaos. The import safeguard
Speaker 2: monitors the percentage of changes. You can set a threshold.
Speaker 2: If an import tries to delete more than, say, ten
Speaker 2: percent of your users, Octa just pauses the sink and
Speaker 2: sends you an alert saying, hey, this looks really drastic.
Speaker 2: Are you sure you want to do this?
Speaker 1: It stops the automation from driving off a cliff exactly.
Speaker 2: Automation is great, but you always need guardrails.
Speaker 1: So when we step back and look at the whole picture, here,
Speaker 1: what's the big takeaway? We've gone from this fragmented mess
Speaker 1: to a unified directory covered by eight octas of cloud.
Speaker 2: I think the takeaway is the evolution of the IKE
Speaker 2: admin's role. In the old days, the admin was a gatekeeper.
Speaker 2: They started the drawbridge and said.
Speaker 1: No, a reactive job, very reactive, very manual.
Speaker 2: Now the admin is an architect. They're designing a system
Speaker 2: of logic and policies that basically runs itself. They're building
Speaker 2: a zero trust environment that actually makes the user experience
Speaker 2: better while making the company more secure.
Speaker 1: So they're not guarding the castle anymore. They're designing the
Speaker 1: invisible for four.
Speaker 2: That's a great way to put it, and they're doing
Speaker 2: it in a way that can scale. You can't scale
Speaker 2: a drawbridge, but you can scale an identity policy.
Speaker 1: I want to leave you with a final thought to
Speaker 1: chew one. We've talked about how the perimeter is gone
Speaker 1: and identity is the new firewall. But as we move forward,
Speaker 1: identity isn't just about people anymore. The identity of things exactly.
Speaker 1: We're integrating bots APIs billions of IoT devices. If your
Speaker 1: smart fridge or your factory robot has a more complex
Speaker 1: excess profile than you do, how does that change the
Speaker 1: architect's job. Are we ready to manage a directory where
Speaker 1: humans are actually the minority?
Speaker 2: That is a terrifying and fascinating question. Managing the identity
Speaker 2: of a toaster is definitely a topic for another deep dive.
Speaker 1: Indeed, it is. Thanks for listening, Stay secure up there.