Posted by Oded Hareven
June 22, 2020
Just-in-time (JIT) originates from the manufacturing industry. Its goal is to eliminate waste by receiving what you need when you need it. JIT has very practical uses in security risk management by ensuring you have the right amount of access, at the right time, for the right duration.
JIT Access, for both humans (developers, DevOps, security) and for machines (containers, automation, configuration tools) needs a JIT approach to enable quick access to on-demand, temporary secrets only when they are needed for a specific task with the correct authorization. With the goal of achieving “just-enough” access and having it “just-in-time” to complete any task you may need in mind, standing privileges must be eliminated. Standing privileges are machine, or user access that is considered “always on.” Meaning a user or machine’s access is never checked to see if the permissions are required to complete specific tasks, introducing a risk of excessive access if these accounts are compromised.
Standing Access
Commonly, enterprises having standing admin or root accounts that have permanent access to your inner environments. They are often left unchecked, from employees that aren’t part of the organization, or internal employees that have more access than they need. Personal accounts are often issued with elevated access on the basis that they’ll be used “some-day” to perform a task that could potentially occur once a month or even once a year.
Standing access greatly increases the security threat exposure surface and becomes a large operational burden to manage and audit numerous accounts floating around. Security teams often have no idea what is happening on these personal user or machine accounts. A critical part of an organization’s credentials/access approach that is often missed is machines carrying a larger risk than human accounts. The reason being, machine accounts significantly outnumber human accounts in most organizations. Because the threat surface is so much larger, human accounts cannot be the only thing that is accounted for.
Let’s visit some security threats and pain points we’ve seen across a variety of organizations:
- DevOps Automation Masters Secrets Management
It’s an operational burden on a DevOps team to manage keys for team members within a configuration management tool that slows down their overall performance.
DevOps uses anything from user credentials, API Tokens, SSH Keys, and certificates in their automation. Configuration management platforms such as Ansible or Chef contain long living vaults that are never updated. Depending on the design of your automation, these secrets can be standing for significant amounts of time without any auditability or insight from the security teams. DevOps doesn’t always have a total security focus, and they frequently forget to rotate keys or remove their standing privileges when deployments are completed.
- Excessive Privileges in Production Environments
An organization may start out as a small IT group that performs a variety of roles in order to stay operational. There are often backups assigned for individuals as well as intermingling of access across a wide variety of authorities. Some organizations even grant everyone high-level access by having very little granularity between different roles and required privileges. Things like a high severity issue defect found can instantly break the best intentions of an organization’s access approach through issuing root or admin privileges to address the problem.
In all the scenarios listed above, there is a massive amount of “permission creep” that opens you up to a variety of threats, and according to Gartner they call out Pillar No.2 of JIT access being “govern and control… to eliminate excessive privileges and govern privileged access according to the privileged use patterns and use cases.” Just as important is Pillar No.1, “track and secure” which is to ensure that all privileged accounts are tracked throughout their lifecycle. This lifecycle ideally lasts only if the elevated access is needed. Events such as a production deployment, removing vulnerabilities, etc. Excessive permissions in production accounts also opens the opportunity for human errors. Having a user without the correct skill level performing admin operations in a production environment can cause a significant amount of unintentional harm.
- Homegrown Applications
Homegrown applications with static users in databases frequently contain accounts with excess permissions that aren’t tracked or revoked in a timely manner. Without consistent updates or revocation of access when tasks are completed, the credentials stored are prone to compromise because best practice security measures aren’t followed. Another common issue is password policies not being set, which introduces the risk of a compromised account that has access to an entire database.
- Lack of supervision
Security teams that are responsible for managing credentials flying around in different tools, applications, with different purposes are impossible to audit and maintain. A key that was issued because a system admin was out on vacation very likely will have no timeout feature and just remain open.
Security teams need that ability to audit all permissions that impact production environments. If your security team is blind to what is happening in production, it becomes impossible to monitor actions being taken with accounts and what exactly accounts have access to. Ideally, there also needs to be analytics, and session recording. Not only for security issues, but also fixing problems that could be caused by human or machine error.
- Vendor Access
Access is often placed in the hands of vendors that are external to your organization. Frequently they’re granted standing permissions to the inner environments of your production environments “in case” it is needed. Third party vendors must be accounted for in your environments, as they are often the culprits for security breaches. Robust controls must be in place to ensure VPN access is implemented, and controls are in place to limit access to your corporate systems.
What is the solution to achieving a JIT approach?
Considering the problems listed above and the known objective, our secrets management solution eliminates these concerns by granting just enough access and right, for no longer than required. Access to perform actions as root or admin are created “on-demand,” for specific, one-time use from a machine or human account. The access would then be unavailable as soon as the user logs off or completes the intended operation.
A comprehensive solution to create true zero-standing access requires an organization to be completely free of any standing permissions across all human and machine access. The solution needs to not only be hassle-free but be able to be used for machine-to-machine and human-to-human access. Achieving zero-standing access is possible, with hassle-free immediate onboarding of a no maintenance SaaS solution. With plugins, SDK, and CLI support for machines, and a web UI with browser add-ons for human access, plus the flexibility to authenticate with identity providers such as SAML or OpenID. Security teams record sessions and issue requested accounts on-demand, with auditability will eliminate the risk of access violating your zero-standing access policy.
Roadmap to implementing JIT across tools
SSH
- Basic
Static Keys placed in DevOps Automation
- Advanced
Certificate issued from a trusted 3rd party, and target user ID is encoded and contains a short lifetime which it auto-expires (Credentialess/Ephemeral Certs).
Kubernetes
- Basic
Static Secrets for each container
- Advanced
Dynamic Credentials
Temporary users to access databases, when container is down the temporary user is deleted
- Expert
Kubectl Plugin
DevOps Administrator will use “Kubectl” or a short lived credential/certificates using a 3rd party identity provider such as Okta (+MFA)
SQL
- Basic
Standing root or admin accounts that are owned by individuals
- Advanced
Ad-hoc privileges are granted for access to the database set to expire at a specific time after the operation has been completed.
CSP-IAM
- Basic
Standing keys or credentials to perform operations
- Advanced
JIT registration of certificates signed by a Certificate Authority. Rules can be created to activate the certificate along with policies, such as duration or if an action has taken place.
With the goal of providing privileged access for humans and machines on demand, you now know the art of managing your organizations permissions. Eliminate your standing privileges, while granting your security team a window into all the potential risks to drive your organization towards a zero-standing-privilege approach.
Achieving Zero-Trust Access is possible with the right secrets management tool, even in production environments. Eliminate the security risk and operational burden of rotating keys, and instead use JIT to remove unnecessary permissions and provide access only as needed for a defined period. Save precious time and hassle, while auditing and recording sessions on both machine-to-machine and human-to-machine access.
