Oort Knowledge Base
  • Home
  • Glossary
  • 📊Dashboard
    • Get Started Dashboard
    • Overview Dashboard
    • MFA Dashboard
  • 👥Understanding your users
    • 📇Users
      • 💾Saved Filters
      • ❓Basic Search & Advanced Query Mode
    • 🩻User 360
      • 🗺️Overview Tab
      • 🔬Activity Tab
      • 📶Networks Tab
      • 💻Devices Tab
      • 🪺Applications and Groups Tabs
      • ✅Checks Tab
    • 🛠️Triaging Alerts and Remediation Actions
    • 🔗Linking User Accounts
    • 🤷User Statuses
  • 🗃️Applications
  • 💻Devices
  • 🧩Configuring Integrations
    • Managed Integrations
    • Auth0
      • Auth0 Data Integration
      • Auth0 Log Streaming & Marketplace App
    • Microsoft Entra ID (Azure AD) Data Integration
    • Microsoft Entra ID (Azure AD) SSO Integration
    • Azure Event Hub Log Streaming for Microsoft Entra ID (Azure AD)
    • Azure Sentinel SIEM Integration
    • AWS
    • AWS User-Based Access [Deprecated]
    • Duo Security Integration
    • Email Notifications
    • Github
    • Google Workspace Integration
    • Jamf
    • Jira Integration
    • Mailgun Integration
    • Microsoft Teams Notification Integration
    • Okta Log Streaming AWS EventBridge Integration
    • Okta Data Integration
    • Okta Workflows
    • Okta Integration Network - Production SSO App
    • Okta SSO
    • Polarity Integration
    • Salesforce Integration
    • SendGrid Integration
    • ServiceNOW Integration
    • Slack
    • Snowflake
    • Webex Notification Integration
    • Webhooks
    • Workday
      • Manual Import (CSV)
      • Report as a Service (RaaS)
  • ☑️Understanding Check failures
    • 🔍Reviewing Check Results
    • 🧹Customizing Checks
    • 📖Cisco Identity Insights
      • Identity Posture Management Insights
        • Access from Denied Territories
        • Allow/Block Email Logins
        • Application Login Bypasses SSO
        • Applications with Expired Secret
        • HRIS Discrepancies
        • Identity Intelligence Client Secret Expiring Soon
        • Inactive Account Probing
        • Inactive Guest Users
        • Inactive Users
        • Missing Value in Mandatory Field
        • Never Logged In
        • No MFA Configured
        • No Strong MFA Configured
        • Okta Long Running Sessions
        • Okta Session Length Policy Compliance
        • Personal VPN Usage
        • Provider User Type Missing
        • Rate Limit Alert
        • Role Assigned to Azure Cloud Only Account
        • Salesforce Direct Login Settings
        • Shared Mailbox Sign In Enabled
        • Slack User Inconsistencies
        • Telecom MFA Limit Reached
        • Unmanaged Devices Access
        • Unused Application for a User
        • Upcoming App Key Expiration
        • User Authorized to Bypass MFA
        • User Has Directly Assigned Application
        • User in IDP but not in HRIS
        • User Password Expiration Failure
        • User Stuck in Non-functional State
        • Users Sharing Authenticators
        • Weak MFA Was Used To Successfully Sign In
      • Identity Threat Detection Insights
        • A Bypass Code Was Used To Successfully Sign In
        • Access From Dormant Account
        • Accounts With Unusually High Activity
        • Active Account Under Heavy Attack
        • Activity From Untrustworthy ISP
        • Admin Impersonation in Okta
        • Admin Role Assigned to User
        • Authenticator Registration Anomalies
        • Code Exfiltration By Guest Account
        • Compromised Session
        • Google Drive File with Excessive Sharing Permissions
        • Impossible Travel
        • IP Threat Detected
          • IP Threat Detected In Depth
        • Login to Admin Console
        • MFA Flood
        • Microsoft Entra ID Admin Activity Anomaly
        • New Country for Tenant
        • New IDP Created
        • Okta Admin Activity Anomaly
        • Rare Browser Activity
        • Registered Location Mismatch
        • Risky Parallel Sessions
        • Service Account Successful Sign In
        • Shared Mailbox Successful Sign In
        • Sign In Threat Detected
        • Sign-in from Recently Created IdP
        • Successful Access from a Previously Only Failing IP
        • Super Admin Login to Google
        • Suspicious Activity Reported by End User
        • Unusual Repo Access
        • User IP in Blocked State
        • User Lock Out Risk Detected
        • User Trust Level Alert
        • Users With Defined Email Forward Rules
        • Users With New Email Forward Rules
        • Weak MFA Manually Activated and Utilized
  • ⚙️Tenant Settings
    • 👨‍💼Role-based Access (RBAC) and Tenant Access Logs
    • Systems Logs
  • 🏥Identity Posture Score
  • 🚨User Trust Level
  • How-to Guides
    • 🔐Accessing and Securing your Cisco Identity Intelligence Tenant
    • 🏎️Can Identity Intelligence analyze behavior and fail checks more frequently?
    • 🛂Importing Known IP Address Lists
    • 🔎Networks Tab & User Investigations
    • 🔁Okta Workflows Webhook Example
    • 🗃️Understanding HRIS Data and SCIM
    • MFA Factors FAQ
  • Public API
    • APIs
  • Troubleshooting & Support
    • API Permissions for Integrations
    • Responsible Disclosure Policy
  • Best Practices
    • 🛣️What’s Next? How to use Identity Intelligence effectively
    • 📚Identity Security Reading List
    • ✍️KPIs for
 IAM Teams
  • Blogs
    • 0ktapus for humans
    • Oort Releases GitHub Integration To Extend Identity Threat Detection
    • Oort Recognized Twice as a Sample Vendor in Gartner® 2023 Hype Cycle Reports™
    • Oort's Response Capabilities: Remediate Compromised Accounts with Just One Click
    • Oort Unveils Dashboard, Providing A Single Pane of Glass for Identities
    • Oort’s New Identity Security Dashboard
    • Oort Unveils Identity Technology Ecosystem, Bringing Identity Data out of Orbit and Into View
    • Oort: Your Security Layer On Top Of Okta
    • Populating the Unpopulated: Challenges of Building a Comprehensive User Inventory
    • Protecting IT Help Desk Teams Against Cyber Attacks
    • Protecting Salesforce Accounts from Takeovers and Ungoverned Access
    • Restrict Guest Access Permissions: Best Practices and Challenges
    • Seizing the Communication Opportunity: Aligning Perspectives in Identity Security
    • Session Hijacking in a Post-Genesis World
    • SIEM vs. Security Data Lake: Why it's Time to Rethink Your Security Program
    • Speaking the Same Language for Identity Security: Identify, Protect, Detect, Respond
    • State of Identity Security research reveals 40% of accounts use weak or no form of multi-factor authentication to protect identities
    • Strengthening Identity Controls: Mapping to CIS CSC and NIST CSF Security Frameworks
    • Strengthening Identity Security with Single Sign-On (SSO) Systems
    • Succeeding with Proper Detection for Identity Security: A Comprehensive Approach
    • Taking a Data-Driven Approach to Identity Security
    • The Concerning Prevalence of Weak Second Factors
    • The Crucial Role of an Identity Security Leader
    • Why I am Joining Oort
    • The Quest for a Passwordless World
    • Understanding Azure Active Directory (Azure AD)
    • Understanding the Implications of New SEC Rules on Cyber Incident Disclosure
    • Unlocking the Power of Zero Trust: The Crucial Role of Identity and Oort's Identity Security Platform
    • Respond Even Quicker to Identity Threats
    • What to Look Out For at Gartner IAM
    • 7 Critical Requirements for Securing Third-Party and Vendor Access
    • Best Practices for Efficiently Responding to Identity Threats
    • Announcing our Identity Technology Partner Ecosystem
    • Catching waves and building clouds
    • Cisco Announces Intent to Acquire Oort
    • CISO Perspectives: Eric Richard, HubSpot
    • Defining Roles & Responsibilities for an Identity Security Program
    • Detecting Session Hijacking
    • 8 Things to Look for in an ITDR Solution
    • Enhancing Identity Threat Detection: Introducing Oort’s New GitHub Integration
    • Founder Perspective: Matt Caulfield On Why He Started Oort
    • Founder Perspective: Vision To Reality
    • Four Reasons Why Traditional SIEMs Fall Short For Identity Security Programs
    • How Oort Partners with Duo for Unbeatable Secure Access
    • Governance, Risk, and Compliance
    • How to Find Inactive Users
    • Identity and Access Management and Oort Explained
    • 5 Identity Security Questions Every IAM Leader Needs to Answer
    • Identity security is bigger than just ITDR
    • Identity is the apex threat vector, so why is identity security still a mess?
    • Identity Threat Detection
    • Identity Threat Detection and Response: what you need to know
    • Identiverse 2023: What I'm Looking Forward to & What Not to Miss
    • Interview with Oort: Best Practices for Managing & Protecting Service Accounts
    • Interview with Alex “Sasha” Zaslavsky (Oort Data Science Lead)
    • Interview with Andy Winiarski (Head of Solutions Engineering)
    • Interview with Nicolas Dard (Oort’s VP of Product Management)
    • Introducing our Latest Integration to Protect Identities in AWS
    • Introducing The 2023 State of Identity Security Report
    • Maintaining a Strong Identity Security Posture: Why IAM Hygiene Matters
    • Managing Machine Identities: A Comprehensive Guide
    • Managing Risk In Shipwreck Diving and Security
    • Monitoring MFA Usage and Adoption: Strengthening Your Security Strategy
    • Okta Breach: Why Attackers Target GitHub, and What You Can Do to Secure It
    • Okta Security
    • Oort and Polarity Combine to Provide Instant Context on Identities
    • Oort + Polarity: Instant Identity Context to Power Investigations and Response
    • Oort Announces $15M in Seed and Series A Funding Round
    • Oort Stacks Go-to-Market Leadership Team Following Series A Investment
    • Oort Extends Identity Threat Detection with New AWS Integration
    • Announcing General Availability of the Oort Identity Analytics & Automation Platform
    • Oort Joins Forces with Microsoft Intelligent Security Association to Bring Visibility into Unmanaged Devices
    • Oort Joins the Microsoft Intelligent Security Association (MISA)
    • Building an Effective Identity Security Program: A Comprehensive Handbook
    • Oort Launches Identity Security Platform in Auth0 Marketplace
    • Oort Launches Identity Security Platform in AWS Marketplace
    • Oort Launches One-Click Remediation Actions for Streamlined Identity Security Response
    • Oort Origins and Our Vision for Identity Security
  • Release Notes
    • Week 22, 2024
    • Week 21, 2024
    • Week 20, 2024
    • Week 19, 2024
    • Week 18, 2024
    • Week 17, 2024
    • Week 16, 2024
    • Week 14, 2024
    • Week 13, 2024
    • Week 11, 2024
    • Week 9, 2024
    • Week 7, 2024
    • Week 5, 2024
    • Week 4, 2024
    • Week 3, 2024
    • Week 2, 2024
    • 2023
      • Week 49, 2023
      • Week 48, 2023
      • Week 47, 2023
      • Week 46, 2023
      • Week 45, 2023
      • Week 44, 2023
      • Week 43, 2023
      • Week 42, 2023
      • Week 41, 2023
      • Week 40, 2023
      • Week 39, 2023
      • Week 38, 2023
      • Week 37, 2023
      • Week 35, 2023
      • Week 34, 2023
      • Week 33, 2023
      • Week 32, 2023
      • Week 31, 2023
      • Week 30, 2023
      • Week 29, 2023
      • Week 28, 2023
      • Week 27, 2023
      • Week 26, 2023
      • Week 25, 2023
      • Week 24, 2023
      • Week 23, 2023
      • Week 22, 2023
      • Week 21, 2023
      • Week 20, 2023
      • Week 19, 2023
      • Week 18, 2023
      • Week 17, 2023
      • Week 16, 2023
      • Week 15, 2023
      • Week 13, 2023
      • Week 12, 2023
      • Week 11, 2023
      • Week 10, 2023
      • Week 9, 2023
      • Week 8, 2023
      • Week 7, 2023
      • Week 6, 2023
      • Week 5, 2023
      • Week 4, 2023
      • Week 3, 2023
      • Week 2, 2023
      • Week 1, 2023
    • 2022
      • Week 51, 2022
      • Week 50, 2022
      • Week 49, 2022
      • Week 48, 2022
      • Week 47, 2022
      • Week 46, 2022
      • Week 43, 2022
      • Week 42, 2022
      • Week 41, 2022
      • Week 38, 2022
      • Week 37, 2022
      • Week 36, 2022
      • Week 35, 2022
      • Week 34, 2022
      • Week 33, 2022
      • Week 32, 2022
      • Week 31, 2022
      • Week 30, 2022
      • Week 29, 2022
      • Week 24, 2022
      • Week 12, 2022
Powered by GitBook
On this page
  1. Blogs

Interview with Oort: Best Practices for Managing & Protecting Service Accounts

PreviousIdentiverse 2023: What I'm Looking Forward to & What Not to MissNextInterview with Alex “Sasha” Zaslavsky (Oort Data Science Lead)

In this interview, , Founder and CEO at Oort, and , CTO at Oort, discuss the important differences to protecting service accounts and what organizations must do to ensure these accounts are properly managed.

Matt: I'm here today to talk to you about service accounts.

Didi: Yes. One of my favorite topics - Service accounts.

A topic that has been coming up a lot with customers recently is that every service account needs to be linked to a real person because you need a throat to choke.

Service accounts have been floating around, and it could be shared mailing lists. They could be the account that a backend server needs to to do their work. Could be on-prem, it could be cloud, it could be on-prem that is accidentally replicated to the cloud with nobody knowing it because somebody flipped the switch on the Azure connector, and now you have a very powerful account with no MFA connected to the internet and no real owner.

And also it's a very common way for a lot of admins to put in back doors. The things to say, I have a service account, it's floating around. It's not really linked to me. And when somebody's taken out of the organization, it's still there. So service accounts is a very interesting concept.

Every different authentication system treats it differently. Okta doesn't have a real idea of a service account. You can create a person and basically name it, but there's no interactive login capability there. Azure has a more mature evolved option for service accounts, but there is no standardized way to govern them.

Matt: It's an interesting concept. I saw service accounts in the news recently. I think Microsoft put out an article on the Mercury attack where the service account that's actually used to sync on-prem ad with Azure AD. Was the one that's under attack and that account often has global admin permissions in Azure AD.

So I can see like this can have kind of catastrophic consequences if you don't lock down those service accounts properly and could be a big impact. Or it could just be a mailbox that I guess has taken over.

Didi: I'll give you an example of a cool thing with a mailbox.

So let's say mailbox is used as a pivot account. Let's say the OR or ops team wants to log in to Browser Stack, that's not what we're doing. We're turning on Okta and SSO to make sure that we don't do this thing. But let's say a lot of organizations, they wanna log into Browser Stack and they don't want one person to own it cuz they have only one owner role.

So you put a shared mailbox as the owner of another cloud service. And now it's used to pivot. So every time I wanna log in, I hit a reset, goes to that mailing list, and everybody can hit the reset and I reset the password, and now I log in. And now the shared mailbox is a defacto service account.

And this is what happens a lot of times that people don't actually think thoroughly. What's in that shared mailbox? Who gets that? Where is it used next? Right? So shared mailboxes are a bundle of joy on their own. And like other service accounts, it needs a throat to choke. Somebody needs to say who can go in, who does come out and how do we know there isn't an external forwarding of those shared inboxes to outside the organization.

Matt: So whose job is it to make sure that those service accounts have an owner and they're configured in a way that they don't allow interactive login or anybody to just come in and take part of those mailboxes?

Whose job is that?

Didi: Nobody's.

Matt: I didn't expect that answer.

Didi: That's a part of the big problem with service accounts. There is no executive owner that owns that concept. If you have a very mature CISO, they'll ask about it, of who owns service accounts and what's the methodology to govern access to service accounts.

And do we know that if somebody logged in as a service account it translates to a real employee. But sometimes it falls there in between the gap of IT and security. And everybody says, not my problem.

Matt: So it sounds like service accounts are sort of a necessary evil because they're sort of a catchall workaround for a lot of situations.

So maybe we have to live with them until we can get on to more of an OAuth based model, API token model, maybe for everything. But service accounts are here to stay. Like what can our customers do or people in the industry do about them in the short term?

Didi: First, at least put in a process even before you talk about products and solutions or our customers.

Think of a process. What is the process of creation of a service account? What's the process? Who, what, where do we tag who owns the service account? If the last single owner has left the organization, what's the replacement process for that service account? Then track if a service account is marked as a service account when it logs in interactively.

Why is it logging in interactively? What's it MFA policy? And know that no MFA policy for service accounts is not acceptable. Put up a real MFA with a real device bound credential. Through that, there are tools out there that allow you to rotate those, so there are solutions for that, and make sure that those are tracked in the audit processes, that there's a ticket associated with a login to a service account, and there's a ticket associated with the closing of this.

Eventually ask when you evaluate PAM solutions. Can they handle those service accounts? And if they can't, that should be a problem. Ask your IGA tools, can they handle service accounts? And if they can't, that's a problem, and build a process around this to make sure that those tools take consideration, those service accounts.

Matt: So I imagine that even if you perfect your processes with a, you know, a ticketing tool, a PAM tool, an IGA tool, service accounts may still be taken over by attackers. So then what, how do you know that's happening?

Didi: Monitor them. Monitor the login, monitor who else has logged in from those accounts. Create an alert if, for example, put in a policy that the log into service account cannot happen from an unmanaged device.

And if such a thing happens, alert. If something like this happens without an associated person, if you want to tighten it up better, make sure that it's associated. Is a device associated with Matt's device, so let's say Matt owns the Okta to Salesforce service account. Make sure that only Matt logs in or has a list of people that can log in.

And if somebody that is registers from logging in from not Matt's, device, not Matt's, associated IP, create an alert, investigate and validate.

Matt: Sure. This is good. So to wrap us up, it sounds like there's a set of things you wanna do.

First of all, service accounts are really important. They can be used by attackers to get escalated privileges. And somebody who wants to take care of them needs to understand not just like putting a product in place, but also putting place processes and the right tools for the right people, getting ownership for them.

And then finally; expecting, even if you do all those things, something can still go wrong. So you need to be constantly monitoring those accounts. And so now is where I guess we need to put in the plug for Oort and what Oort does.

Didi: Yes. Well before we plug Oort, the important part is the make sure that the service account is always linked to a person or a group of people, but usually one throat to choke, always one throat to choke.

And what or does today? It monitors interactive logins from service accounts that are not supposed to interactively log ins and, and alerts. In a coming linked, uh, account feature, we will be able to link accounts to people and of course we highly recommend connecting the trouble ticketing system to at least adhere with a process of opening a ticket before accessing a service account.

Oort is an identity-centric enterprise security platform. As a turnkey solution for Identity Threat Detection and Response (ITDR), Oort is providing immediate value to security teams by working with existing sources of identity to enable comprehensive identity attack surface management in minutes. Led by a team with decades of domain expertise across identity, networking, and security, Oort is backed by venture capital investors including Energy Impact Partners, .406 Ventures, Bain Capital Ventures, Cisco Investments and others. Market-leading technology companies, like Collibra and Avid Technology, rely on Oort to provide full visibility into their identity populations. To learn more, please visit .

Matt Caulfield
Didi Dotan
oort.io