Skip to content

Akeyless unveiled the world’s first Unified Secrets and Machine Identity Platform to address the #1 cause of breaches. Discover Why & How.

Combating Insider Threats from the Inside Out

Insider threats are one of the most difficult risks for security teams to manage because most employees require some level of trust and privileges to perform their roles. Managing this risk involves detecting and containing the undesirable behavior of trusted accounts in the organization. This undesirable behavior often goes undetected for a long time. 

Insider threat types can be categorized into three threat actors:

  1. Employees with malicious intentions who decide to abuse their privileges to sabotage or steal data for personal reasons of financial gain or spiteful feelings towards the organization. 
  2. Negligent employees who introduce risk to an organization by accidentally exposing sensitive information, for example through misconfiguration or not following good security practices.
  3. Finally, external threat actors sometimes exploit internal credentials they stole through malware, phishing attacks, or other means.

Recent trends like “The Great Resignation” further increases the risk of disgruntled employees bringing harm to an organization as a final act of contempt. For this reason, HR departments need to work closely with security teams to ensure they have procedures in place to adjust or revoke credentials and privileges when employees resign or show signs that they are intending to quit. 

However, more fundamental changes lie behind the increase in insider threats. Security concepts have developed along with the way that corporate infrastructure has evolved. Gone are the days when the on-premises, or “inside,” network was considered secure, and everything outside was insecure. Many employees who were already increasingly mobile, are now permanently remote. Corporate security coverage has had to change drastically because these mobile users are no longer protected by on-premise security solutions that monitor user behavior and control endpoints’ security. The tight grasp security teams once enforced on corporate workstations has loosened considerably: users now expect to use their own personal devices, such as phones and tablets, for work tasks. In other words, organizations’ attack surfaces have expanded, only to be amplified by resources in the cloud that also require access.

Curtailing Insider Threat

To limit the impact of insider threats, security teams must limit the “blast radius” in the event that things actually go wrong; when an insider risk turns into an actual insider threat. The amount of damage that can be accomplished by an insider threat is directly correlated to the number of privileges or authorizations associated with the role of the user. Therefore, the first step in limiting the blast radius is to ensure users only receive the very least amount of privileges that allow them to perform their role. The industry term for this concept is Role-Based Access Control (RBAC).

Now that the legacy perimeter concept, together with its location-centric (inside vs. outside) access policies is no longer viable, access control policies must be identity-centric. The next step to limit insider risk comes from no longer extending any “implicit trust” based on a connecting identity’s location, and instead to apply increased scrutiny before allowing connections to be established. This much talked about—and arguably much overhyped—model is known as Zero Trust. The Zero Trust model aligns very well with limiting insider threats because access is now dependent on evaluating the privileges of an authenticated identity, and provisioning the appropriate access levels on-demand. With this approach, insiders can only operate within a tightly controlled environment. Here are three simple, actionable steps to control access, and to summarize the “three J’s” core of Zero Trust as recommended by Dr. Chase Cunningham:

  1. Justify access based on identity and role – Both humans and machines (such as applications that access a database) must justify who they are, and why they need access. For example, you wouldn’t just let anyone enter your house and let them roam about freely, just because they said their name is Mike. If you can check Mike’s ID, and you were expecting him to come and fix the plumbing, that’s another story.
  2. Just-in-time – Access should only be given upon request, and with the least amount of privileges possible. Going back to our example of Mike the Plumber, he only needs access to your house right before he fixes the plumbing. In addition, he only needs to examine the sinks and showers; he has no business in your office.
  3. Just Once – After a job is finished, or a reasonable set time for the job expires, the access must be terminated, the credentials deleted,  and the whole process starts again, at the beginning. You don’t need Mike to stay overnight, and he doesn’t need to get back inside again when the plumbing is fixed. 

The last two aspects of Zero Trust—just in time and just once—are frequently overlooked, and we will address them further below.

More Credentials, More Problems

As with most problems, the best solution to fixing them comes by preventing them from occurring in the first place. Credentials, certificates, or keys (together called “secrets”) are there to prove an insider’s identity and as previously mentioned, attackers will use these secrets to assume the role of an insider. According to Verizon’s 2022 Data Breach Investigations Report, 61% of breaches involved hacked credentials as a means to get into an organization’s infrastructure. In addition, an IBM Security study (The  Cost of Insider Threats) shows that 29% of all credential thefts involved the theft of privileged users’ credentials. This makes a lot of sense as hacked privileged accounts have a wider range of access, and provide more opportunities for attackers to move laterally, and elevate their privileges even further.

It is clear that secrets need to be protected with granular access control, to contain the impact of stolen insider credentials. Statistically, having more secrets in rotation increases the probability of insiders leaking those secrets. Unfortunately, there are painful,  recent examples where attackers leverage leaked secrets from a repository, to gain access to other resources such as Cloud Service Provider (CSP) platforms.

Just in Time, Ephemeral Access: The Key to Preventing Insider Threat

The previously described secrets are static in nature. Once they are created, they remain valid until someone changes their value. Sometimes applications enforce a periodic password reset, or industry regulations dictate a frequency. For example, the PCI-DSS regulation requires passwords to be reset every 90 days. But 90 days is still a large window for an attacker to enter an organization’s infrastructure with a stolen, valid credential, and deploy a killchain

The best approach to mitigate the risk of leaked static secrets, is to eliminate standing permissions altogether. Imagine a world where a client (either a service or a human) uses a database account only for the time it’s actually needed, and after that, the account is magically gone… That creates a situation of zero-standing permissions. Where there are no permissions, there’s no identity to manipulate and hence, lower risk. 

With dynamic secrets, clients get access to a resource with the minimum privileges they need to accomplish a specific task, for the minimum time required. Dynamic secrets are also known as “Just-in-Time” (JIT) credentials, a term borrowed from the manufacturing industry where materials are ordered only when needed, to improve efficiency. 

A sample scenario of JIT is where a database administrator (DBA) needs to access data on an SQL database. The authenticated DBA requests the credentials from a centrally available secrets management solution, acting as a dynamic secrets vault. In turn, the vault creates a credential on the SQL database target, with the appropriate permissions for that client’s role. After the session ends, or when the credential’s time-to-live (TTL) expires, the vault revokes the account.

Conclusion

To control insider risk, organizations need a tight grasp on controlling access for identities, and ensure they always operate in environments with tightly controlled privileges. When an insider risk turns into an insider threat, it is important to predict and limit the “blast radius”, which is directly related to the privileges associated with the identity’s role. With the right secrets management platform, organizations can limit the consequences of insider threats using Just-In-Time Access and prevent credentials and secrets from being exposed. Security teams who need to enable DevOps, cloud transformation, and Zero-Trust access, should investigate a secrets management solution that can support these initiatives while keeping credentials of all types safe and limited.

Akeyless Vaultless Platform for Unified Secrets Management and Secure Remote Access

The Akeyless Vaultless Platform is a purpose-built SaaS solution that allows organizations to securely store their secrets in an encrypted vault, on a Zero Knowledge platform. 

Akeyless enables Zero Trust access scenarios for human and machine identities, with Just-In-Time (JIT) access functionality. JIT tightly controls the access and privileges of connecting identities, by injecting temporary secrets into sessions for authenticated identities. These credentials are automatically provisioned on the target (for example, a database) on-demand, and revoked after use. This mechanism works for traditional targets but also helps organizations roll out their hybrid multicloud strategies with ephemeral resources. JIT access virtually eliminates the risk of an attacker assuming an insider role with stolen insider credentials, because they’re only valid for seconds or minutes, rather than days or months.

Akeyless provides a unified policy engine for Secrets Management and Secure Remote Access to integrate human and machine access control on a centralized SaaS platform. The Akeyless Vault platform covers key access use cases such as:

  • Developer Access: Secure access to servers, management consoles, and code repositories
  • Work from Home: Securing employees’ access outside the perimeter to corporate applications
  • Third-Party Access: Secure external access to your critical IT resources, applications, and databases
  • Machine Access: Secure remote access between machines, containers, services, and applications

With Akeyless, security teams have full visibility and control over how insiders use their secrets, and the ability to share this information with SIEM and/or SOAR solutions. By standardizing to a central vault, developers always have access to the secrets they need to perform their role, and use standardized and simplified workflows, regardless if the workloads and services are on-premise, or on a cloud platform. 

Akeyless enables secure access to workloads and applications across hybrid multicloud environments of any size. Schedule a demo to see how Akeyless would limit insider risk at your organization.

Ready to get started?

Discover how Akeyless simplifies secrets management, reduces sprawl, minimizes risk, and saves time.

Book a Demo