Application Security Best Practices

Application Security: Best Practices for Secrets Management to Protect Applications

Securing Application with Secrets Management

Published November 29th, 2020 by John Walsh

Application Security Overview

Good application security (AppSec) prevents unauthorized access and modifications to apps by controlling access to sensitive information like application secrets.  Secrets management is critical to protecting these application secrets and preventing unwanted modifications to apps.  Let’s take a closer look at their importance and how to keep them safe.

Defining Application Secret

Firstly, what is an application secret? In simple terms, it’s anything that helps the application work, but that you want to keep private. Examples include a database username and password, a connection string, OAuth authentication and authorization secrets, and other similar access tokens. If these secrets become publicly available, you need to change them, ideally easily and quickly, across your applications.

Application Security and Secrets

Application secrets need to remain secret to secure applications, so how do we do this? We face many challenges in not just enterprise applications, but also in day-to-day access to smaller, distinct applications. As a tech lead or development operations lead, you may create and manage a huge number of secrets across your products or applications.

Some technologies, like VMWare and Kubernetes, come with their own secrets manager modules. Cloud Service Providers (CSPs) also provide their own secret management services. The issue with these comes down to access from “outside” and being vendor locked. If you have services in Amazon Web Services (AWS), Azure, and other providers, you may not want to share secrets between those platforms. This leads to the next challenge, surface area.

This may seem obvious, however, surface area is important. If you have secrets copied into multiple managers on multiple providers with a slew of different access points, you are opening yourself up, creating more opportunities for hackers to attack your services.

When it comes to accessing secrets, continuous integration/continuous delivery (CI/CD) processes are also a big consideration.

You may, for example, have nightly processes auto-generating and auto-removing files for a website built in Netlify. Those files are generated based on an API requiring an OAuth secret. If other services use this same secret, consolidation would help and a secret manager that is non-platform specific or vendor locked is a much better option.

With the trend of moving to distributed systems and microservices, there is no guarantee that all services are developed or deployed in the same way. This challenge is about keeping your processes running smoothly and securely.

Applications having access to more secrets than they need is an interesting challenge. Yes, they are all your applications and processes, and if you use a single secret manager, how do you reduce those attack vectors even further? You don’t want all applications having access to all secrets at the same time.

We don’t want to revoke secrets, although it does happen. Usually, it’s due to a bad accessor, insecure storage of secrets, or even accidentally exposing them to 2000+ viewers while doing some live development. How do you easily change and distribute a new secret across your whole ecosystem? We don’t want to be re-releasing services or changing config files or environment variables manually. We want to click once or, at least, as few times as possible.

The final challenge we’ll discuss here is when to access your secrets. This is subjective and can depend on the environment you are running. However, we feel it’s a case of accessing secrets at a point where you don’t need to rebuild your whole codebase, however, at the same time, don’t access them on every API call.

Although this is not a definitive list of challenges, hopefully it helps you visualize potential vulnerabilities in your secrets security.
Best Practices and Solutions
We have discussed several challenges above on how to keep your surface area to a minimum and yet allow your applications easy access at scale to your secrets. So, let’s move on to a set of best practices you can put in place as possible solutions to those challenges.

Using a single source for secrets is the first step. In our challenges, we mentioned that secret managers are great, however, you can be vendor locked and access across platforms isn’t as secure as it could be.

If you are using a single vendor, then this has no real effect on you, and it’s okay to use something like Azure KeyVault or AWS Systems Manager. On the other hand, if you want external access outside of your cloud service provider (CSP), then Conjur is a fantastic option. With Azure and AWS authentication integration through several SDKs, and an API for retrieving secrets, you are not locked to just a single CSP. You have options where your application is hosted, yet still keep a single source of truth. Using a single secret manager also reduces the attack area.

Solving the CI/CD challenges is easy when using a single store. However, your processes may be hosted outside your CSP. As a consultant, you may have several clients and projects in multiple cloud providers such as Azure and AWS.

If you are using AWS, your processes can be hosted inside AWS with CodeCommit, CodeBuild, and CodeDeploy (the Code Suite), making access to items in Systems Manager “easy.” The same can be said for Azure and Azure DevOps. The issue comes when you are looking for anything outside those vendors. As we discussed, a single external secret manager is your best option.

Restricting applications and services to only the secrets they need gets complicated with the slew of secret managers out there. They don’t really offer auditing of secrets, and when you try to grant permissions per secret, you end up spending more time than you should setting up. It’s possible, but there are easier, less time-consuming ways.

Conjur is again a good example of a solution, with its secret auditing tools providing the information needed to grant secrets access quickly and easily. Carefully mapping out which applications need to access secrets helps you manage your security, ensuring no application accesses more than it needs.

The last solution we’ll discuss is when to access and how to revoke your secrets, generating and loading new secrets quickly and easily. As we mentioned, you should load secrets once at the “right” point. However, deciding when your application should load secrets is subjective.

The key point in this, however, is we believe you shouldn’t be rebuilding from your codebase when secrets change, and you should not load these more than once per instance of the application or service using those secrets.

The caveat to this is, if a secret is changed, how do you reload those secrets? In your services and applications, you may do two things.

The first is establishing a reset trigger. This reloads the service or application when that trigger is pressed and therefore reloads the secrets.

The second, which is more common and automated, is to use your CI/CD processes to redeploy the services or applications affected by the change. This, therefore, reloads the secrets and your application. This does assume that your CI/CD processes are set up in such a way to make this possible.

If you’re using a solution like Conjur, your secrets aren’t locked into a single platform. But it does offer seamless integration with OpenShift and Kubernetes Secrets, AWS IAM, and Azure Authentication, so your developers and DevOps teams can use Conjur and leverage their existing platform knowledge whether running on-premise or in the cloud. Conjur works with applications written in any language, and can secure DevOps tools and CI/CD pipelines.

Below is a simple architecture diagram of where Conjur may sit within your enterprise applications.

Application Security Architecture

If it seems a little simple, that’s due to the fact that it is “just that simple.” If you have any secret that is needed by any part of your application, you go to Conjur to get it.

  • Connecting from your AWS Lambda function to Azure CosmosDB, go to Conjur to get the connection secrets
  • Connecting from your Azure VM to AWS DynamoDB, go to Conjur to get those parameters.
  • Connecting to external APIs that require secrets, yes, you guessed: go get them from Conjur.

With all the best practices and solutions we talked about you can implement this in your enterprise applications with ease. I have.

Application Security Next Steps

Above, you have read about the challenges of application security related to secrets management and some solutions and best practices to solve these challenges. CyberArk’s Conjur helps cure your secrets headaches by consolidating many secret managers into a single solution, with painless management to ensure only the applications you authorize can access your secrets.

Get started with our new hosted interactive tutorials securing CI/CD pipelines, securing Ansible automation, and securing Kubernetes secrets to start securing your applications. To learn more, participate in the CyberArk developer community forum and join our DevSecOps newsletter bursting with news and helpful tips. When you are ready to secure your application secrets, check out Conjur’s quick start guide to install it yourself. You will find the information you need to get you going and manage your secrets with any and all cloud providers.