How Security Islands Prevent Effective Secrets Management

July 2, 2020 Geri Jennings

Secrets Management

The past few years have been an exciting time for the tech industry. The DevOps revolution has led to increased adoption of Kubernetes. Modern software development toolkits enable developers to easily and consistently build, deploy and scale applications – while keeping a record of all configurations as code.

We’ve also reached the point where – thanks to some prominent data breaches – we recognize that security can’t be an afterthought; it is an important consideration of its own. This realization has led to a greater focus on what secure, cloud-native software development looks like.

Because there was frequent data loss in the early days of DevOps, often due to credential mismanagement, many of the tools that grew out of the advent of DevOps now have their own systems for secrets management. When you use multiple tools to build, deploy, configure and maintain your applications and they each have their own mechanisms for managing security policies and access control, you end up with what we call “security islands:”

A security island is:

A tool or platform that comes with its own built-in security components (that manage secrets, access control, audit, compliance, etc.), but 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 happen when a tool doesn’t have well designed security features like fine-grained access control or detailed transaction audit. It may not securely store data at rest or may not be designed to be interoperable with other tools. Whatever the cause, the result is the same: implementing security for the suite of tools associated with the security island must happen piecemeal and without any centralized oversight.

When your systems are set up so that you’re forced to deal with security islands, you suffer from a lack of consolidated audit and access control and it’s difficult to delegate authority to manage subsystems in any standardized way. You also lack a centralized view of your entire security landscape, which makes it increasingly difficult to manage at scale. Here is an example to illustrate what this might look like in practice:

You use Jenkins CI/CD pipelines that need one set of credentials to deploy applications to staging servers and run tests and another set of credentials to deploy the applications to production. Once the applications are deployed, each individual app or service will need its own credentials to connect to production databases and APIs.

Your Jenkins server can be set up to store the test and production deployment credentials in Jenkins secrets or the credentials plugin. When your apps are deployed to production in AWS, you can use AWS Secrets Manager to store the database secrets and API keys.

This may work initially, but if this becomes just a little more complex, it can quickly prove to be too unwieldy to scale and manage all your security through your DevOps tools. Not only do you now lack an ability to easily delegate, manage and audit, but you’re also struggling to securely scale your team’s applications. If that’s not bad enough, the situation can get even worse.

Consider another team deploying their applications to the same staging and production environments using their own CI/CD. How do you keep the keys consistent across both environments? How do you manage rotation and ensure that only the people and applications that need those credentials are able to access them?

And, as your team’s applications gain increased market traction and you start deploying to multiple clouds for resilience and disaster recovery – you’ve just added yet another security island. Bottom line, as your team’s apps become more successful, the security posture worsens.

In addition, if security is too complicated, teams will choose their own security tools and processes that are outside of official policies. This is a kind of human security island that is often referred to as “Shadow IT.”

Getting to a Better Place

The modern pipelines we’ve created are well designed to improve flow and velocity and to enable us to ship our code, but they are not always built for security. The benefits of these interconnected systems are real and we’re not going to get away from having suites of disparate tools. We can start to improve the experience of managing them when we have technology that enables us to tie them all together.

So, how do you escape from the security islands and weave your tools together in a way that connects them with your established systems of trust?

When you have a way to operate without security islands 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.

To manage privileged access for applications throughout the software development lifecycle, 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 privileged access 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 just such a centralized system for managing application privilege in dynamic environments. We built Conjur’s policy engine so that you can put the principle of least privilege into action, and make sure that only the applications and users that should be accessing credentials are able to retrieve them.

We make it easy to onboard new applications and to deploy applications configured to connect to Conjur by providing platform integrations that work with the native properties of platforms to identify apps and avoid the secret zero problem altogether. We make it simple for applications to access the secrets they need or do away with the need for secrets away entirely with Secretless Broker. If you’re interested in learning more, please visit us at conjur.org or join us on the CyberArk Commons!

Previous Article
Masking Malicious Memory Artifacts – Part II: Insights from Moneta
Masking Malicious Memory Artifacts – Part II: Insights from Moneta

Introduction With fileless malware becoming a ubiquitous feature of most modern Red Teams, knowledge in the...

Next Article
Top 5 Features of v11.5: Flexibility for the New Normal
Top 5 Features of v11.5: Flexibility for the New Normal

The world is changing rapidly and privileged access management (PAM) is no exception. Today, we released th...

Check out our upcoming webinars!

See Webinars