Security Islands

The last decade has been an exciting time for the tech industry, with the advent of collaborative business practices like DevOps and modern tooling that enables us to go faster than ever. It’s made it really exciting to be part of a software team at a tech company and we’ve probably all heard the adage that “every company is now a tech company”.

There’s been an explosion of products on the market that are designed to help us achieve our business goals. But with the advent of these new workflows and tools, we’re beginning to identify additional risks that we need to mitigate if we’re going to protect our systems and our customers’ data.

In general, the modern pipelines we’ve created are well designed to improve flow and velocity and allow us to get new code rapidly built, tested, and deployed but are not always built for security. In fact, the threat models and vulnerabilities that need to be addressed expand.

One threat vector that we worry about in particular is exposed credentials and secrets, like those that are inadvertently shared in code repositories like GitHub or that may be exposed by vulnerabilities or over-privileging in the DevOps tools that have access to these secrets.

When you have all of these tools, and they each have their own mechanisms for managing security policy and access control, you end up with what we like to call “Security Islands”:

A security island is:

A tool or platform that comes built-in with its own security components (that manage secrets, access control, audit, compliance, etc) but that does not facilitate interoperability with other tools and/or aggregation of security policies, management, and audit data.

A security island is an isolated subsystem that makes it harder to manage the security of your system as a whole. This can be because the tool isn’t fully featured or isn’t interoperable but the end result is the same, that implementing security for the tools must happen piecemeal and without any centralized oversight.

Security Islands

When your systems are set up so that you’re forced to deal with security islands, you suffer from a lack of centralized audit and access control and it’s difficult to delegate authority to manage subsystems in any standardized way. You lack a centralized view of your entire security landscape, and it is increasingly difficult to manage at scale.

In addition, it’s possible to build human security islands. If security is too hard or complicated, teams will choose their own security tools and processes that are outside of official policies. In general this is often referred to as “Shadow IT”.

Getting to a better place

At CyberArk, we want to enable you to build a Continent of Trust that allows you to get away from security islands and instead weave your tools together in a way that connects them with your established systems of trust.

We’re not going to get away from having suites of disparate tools, but we can start to improve the experience of managing them by finding tools that let us tie them all together.

When you build a continent of trust, you get the benefit of centralized audit, access control, and administration. It’s easy to delegate authority and to manage at scale. You have the benefit of a centralized view of your overall security landscape and how the individual machines and services interact with each other.

In particular, to build a continent of trust for application privilege management, you need a system that lets you define your entire infrastructure, declare who and what can access which resources, audit all connections that are made, and monitor for unusual behavior.

In practice, you want the system that you use for centrally managing application privilege to enable you to:

Automate granting machine identity to applications and processes (like CI servers) Deploy applications so that they are prepared to seamlessly authenticate with the resources they need Centrally manage access control Reduce complications for developers so that Shadow IT is no longer necessary

On the Conjur team at CyberArk, our mission is to create such a centralized system for managing application privilege in dynamic environments. We provide integrations (like our Kubernetes authenticator ) to make it simple to bootstrap Conjur machine identity, and provide tools like Summon and Secretless Broker to simplify the process of connecting applications to the resources (like databases and APIs) that they need. We do this in a way that takes the onus off of developers as much as possible.

If you’re interested in learning more, please visit us atconjur.org or join us on Slack !