Alex and I founded ConductorOne, in part, because we wanted to “shift identity left.” For context, “shift left” is the practice of moving a critical function, like testing or security, to a step earlier in the pipeline. Identity is fast becoming a key battleground for cyber attacks. In as much, companies need help securing critical data and systems against these attacks. We believe shifting identity left is the way to do it.
What Shifting Security Left Means
When I was starting out as a software developer in the early aughts, security came into play after software was in production. Engineers built software, ops teams deployed it to production, and security teams poked at the application to find vulnerabilities and issues. It’s obvious now, but that was less than ideal. For starters, it’s much easier to catch and address critical security issues in code or configuration while it’s still in development. Finding these issues earlier in the pipeline also means you’ve mitigated vulnerabilities before they become a risk to your organization. Illustratively, at ConductorOne, when a developer writes code, the team includes security best practices in the initial code review. This is “left” of when the code goes into production.
An Ounce of Prevention, as They Say
Security defense is typically modeled as three parts: (1) prevention (2) detection and (3) response. Shifting security left means focusing time and resources on preventing issues, before you have to even detect and remediate them. The latter two efforts are extremely expensive (just ask your CISO). It takes a lot in terms of products, infrastructure, and people to scale a detection and response discipline. It’s much more efficient and effective to solve broad-based architectural issues with a shift-left philosophy. It lets your detection and response teams focus on acute issues and not waste their time mitigating broad-based issues that could have been easily addressed with better technology and process upstream. I love a good adage, and “an ounce of prevention is worth a pound of cure” gets at the heart of the shift left mindset.
Shift Left on Identity
We believe that the “shift left” principle should be applied to all areas of security, especially identity, and not just software development. As identities and SaaS proliferate, these problems are going to 10x in scale in the near future. The growing adoption of Zero Trust and MFA have meant that network-based and password-based attacks are now harder to execute. (And I’ll give myself a small pat on the back here, since I co-founded ScaleFT, the Zero Trust networking company, which was acquired by Okta, a leader in MFA for workforce and customer SSO. In fact, Okta is where my co-founder Alex Bovee and I first met.)
We all know hackers are like a penny-pinching grandma–they’ll always choose the cheapest way to get what they want. Why would an attacker go to the trouble to hack Twitter’s systems, when they can scoop up an employee’s credentials that gives them permissions to make API calls? In Twitter’s specific case, whether it’s a rogue employee or social engineering, targeting identity has been an effective attack vector, because someone somewhere in their org had too much birthright access, combined with a lack of permission escalation and attenuation.
The “shift left” fix here would be to deliver fine-grained permissions (e.g. you can make this type of API call, but not that kind, using this kind of app, but not that one), with automated workflows that help employees get more permissions when they need them, and for no longer than they need those permissions for.
Our Bet on Shifting Identity Left, as a Product
Here is how IT and security orgs should think about shifting left on identity. Coincidentally, it’s also where the ConductorOne platform is headed 😀.
Automation
Remove manual processes from how you grant access to apps and infrastructure. Spreadsheets of access matrices are not programmable, and personally give me the hives. Just like in Zero Trust when we stopped using network addresses as identity, we need to have declarative approaches to provisioning and who can do what.
Orchestration
This is a multi-party problem. Many applications you oversee have many owners, so you must have a model for dealing with disparate components.
Delegation
The people most familiar with who should have which access and permissions are often not the same people who control security policy. (This is very similar to detection and response/security teams vs. developers in the movement to shift security left.) You want the people who can have the biggest impact to be empowered to be successful.
Ready to Shift Identity Left With Us?
Our team is all in on shifting identity left, and we’ve been heads down building the first iteration of our identity orchestration and automation platform. If you’re the IT pro in charge of identity and want to be amongst the first to try out ConductorOne, sign up for the waitlist on the bottom of our homepage.
