The Principle of Least Privilege

Access shouldn't always be on

Passwords are effective believe it or not. Convenience is the problem. It causes us to compromise on security. For example, we know our passwords should be long, complex, and contain a variety of characters. We also know they should be frequently changed. Hand on heart, who does that for every one? We don’t do it because it’s not convenient.

Similarly, people want always on access because it is convenient. But, for the same reason that it’s not a good idea to set your password to ‘password’ it’s also not a good idea to have standing privileges. These are open gates to your corporate ‘kingdom’. Weak points that attackers can manipulate to gain access to your critical applications, infrastructure, and ultimately data, delete or modify it, by assigning themselves permanently elevated permissions. That's why the principle of least privilege is so important.

Passwords used to be enough

The role of the corporate security team was once to defend defined perimeters using network and firewall protection tools. Cyber security was a simple matter of keeping unauthorized access outside the perimeter. Privileged Access Management (PAM) was about controlling who had the keys to your kingdom.

Imagine a pre-cloud business as a ten-story office building. To gain access you buzz in at the gate and identify yourself at the front desk. You travel in the elevator to the correct floor, where your identity is checked again. You could visit another floor in the building if you choose to. However, once verified, you are trusted to do the right thing. These controls are effective only because access is contained within the walls of the building. Just as security used to be physically confined to the corporate network.

Password-based PAM is no longer enough

Today, enterprises operate on an increasing number of public cloud platforms and applications, 80-100 on average. The building in our analogy (your legacy network) was expensive. But it was worth it. It was your fortress. Today, you have multiple buildings in the cloud and they’re inexpensive. There’s no limit to how far you can scale digitally. But your perimeter is gone. Your buildings are multi-tenancy and you’re relying on the owners to keep them secure. You’re relying on Amazon, or Google, or Microsoft to take care of your data, because it’s convenient to give that responsibility to them.

And, they’re not doing a bad job. They’re just not doing the same job as each other. They do it in different ways so that it’s almost impossible for you to understand what cybersecurity measures are in place for protecting your data. And, they don’t necessarily make the same decisions that you would when it comes to accepting risk. They certainly don't have the principle of least privilege access top of mind. Risk isn’t a yes or a no, it’s a choice. When you’re not the one doing the choosing, vulnerabilities can result.

This model perpetuates a checkbox mindset when it comes to complying with security standards. Those checks are not always thoroughly vetted and validated. Let’s use a TV streaming services company to illustrate why that’s the case. This type of service provider’s core value is in delivering competitive broadcasting services. Not in providing unbreakable data security. Sure, they have security checks in place. But these are on their checklist, rather than a part of their value proposition.

At the same time, analyst group Forrester is warning businesses of the growing need for Cloud Identity Governance. How do we gain control of our own security posture, then? Do we go back to the old way of building a wall around our corporate data? Theoretically you could install your own gate and ‘security guards’ in the form of a monitored Virtual Private Cloud (VPC). But in doing that, you lose both your cost and convenience advantages. Not to mention your ability to gain a market advantage through being progressive. Truthfully, DevOps cannot operate efficiently in the confines of a perimeter. Yet your users are going to continue to request new mobile apps that sit outside of core corporate systems. And, Security doesn’t have the time or resources to protect every SaaS solution.

So how can you arrive at a true DevSecOps capability? You reinvent the way security is done, for a multi-cloud world.

The principle of least privilege access

The answer lies in an enterprise cloud infrastructure flexible enough to support a fast-growing landscape of mobile apps, remote users and BYO devices, yet secure enough to minimize external security threats and internal misuse. One that supports the principle of least privilege.

Achieving a continuous state of least privilege assumes zero trust. In a Zero Standing Privileges (ZSP) model human and non-human users gain access to restricted resources the moment they need them, only for as long as they need them. This Just-In-Time (JIT) permissioning methodology results in the least number of open privileges at any given moment in time.

Privilege right-sizing is an important component in achieving a state of least privilege within a zero trust model. That means, not only are privileges only given when needed, and only for a limited time, but users' minimum viable privileges are provided, to reduce the attack surface for hackers. You don’t need a bunch of keys to open a door when one key will do the job.

Dynamic Permissioning enforces a least privilege model for human and non-humans alike

What we are talking about here is Dynamic Permissioning, a cloud security 2.0 technology for managing privileged access. A Dynamic Permissioning platform, like Britive, leverages advanced data analytics to assess access requests across multiple events simultaneously. Intelligent algorithms match these requests against the relevant entitlement policies, as well as behavioural data, in order to assign right-sized privileges in real time. Once a task is complete, or the session ends, those privileges automatically expire. Managing privileged access dynamically in this way lets you maintain a consistent position of least standing privilege. This applies to both: human and non-human or machine IDs.

Returning to the building analogy, Dynamic Permissioning means I gain access to the 10-storey building at the start time of my meeting. I can stay for one hour only - the duration of my meeting. I have access only to a specific meeting room on a specific floor, and I am escorted from the building afterwards, returning my pass on my way out.

Such is the level of assurance offered by a least privilege security model supported by Dynamic Permissioning that it allows organizations to become true innovators. Security is happy to let DevOps go crazy for the controlled time they spend accessing privileged areas of the infrastructure, precisely because that time is limited and they leave a closed door behind them. The window of opportunity for malicious activity is minimized, and the payoff is that they are creating revenue-generating applications.

Key considerations for establishing a least standing privileges environment

1. API first

CSP and SaaS services, like any other piece of software, are governed by rules. An API first platform tells you that your PAM solution understands and integrates with those rules, whatever they maybe, instead of getting around them by using its own rules. API first is critical to an ever-expanding SaaS and cloud service provider landscape.

2. Automation

The key to automation is ensuring standardized and repeatable processes are dependable and secure. Operating within the confines of a CSP or SaaS solution’s APIs is fundamental. Like a Rubik’s cube, understanding the order and rules that confine operations is the basis for lining-up all the colors appropriately. If your security efforts are defined around factors that ignore how CSP and SaaS resources fundamentally work, when the Rubik’s cube introduces a new dynamic with a new dimension, your house of cards will fall apart. Has Microsoft ever done an update that broke your security?

3. Reporting

Understanding usage across a multi-cloud heterogenous world requires collecting, normalizing and interpreting data using a standardized vocabulary and definition of high risk. Focusing on one CSP or SaaS with their native reporting capabilities leaves room for error in missing the bigger picture when making time-based critical decisions about how resources and privileges are being used by both human and non-human accounts universally.

What does success look like when you employ the principle of least privilege

For forward thinking organizations that succeed at adopting least standing privileges the future is bright. Security will move away from being the perceived inhibitor of progress that enterprise business units avoid engaging with, to a true business value enabler. Security teams will be able, from a defensible audit position, to attest to satisfying the requirements of compliance mandates, as well as to reducing the threat landscape and minimizing overall risk to the business. When everyone goes home at the end of the day, turning off the proverbial lights, literally there will be no rogue API keys or administrator accounts continuously available for the taking by attackers. Security can ultimately provide the convenience and speed of operations so desperately asked for that allow teams like DevOps to move securely, fast and on-demand!