Prevent Access Leakage Using Credential Storage
Digital-native businesses (tech-startup) build most of their tech ecosystem in-house. In the last few years, there are several incidents around access leakage to that ecosystem.
In some security incidents, access leakage leading to more severe events like business data exfiltration. Looking at how digital-native businesses grow, they build new features in a matter of weeks, if not days. The market demand requires a software engineer and DevOps team to focus on speed in their delivery effort. In between those efforts, access to the network, server, or database is sometimes not adequately protected. Reference from Mitre here.
Objective
Providing a solution of credential storage to give required credentials for the application to run.
In most modern applications, it requires the following credentials.
- DB user & password
- Encryption key
- Certificates
- Cloud Platform credentials
- Third-party API Token
Threat Vector
Pragmatically, we can observe from the past incident that the threat vector can be mitigated. But do we?
To answer that, we need to identify the threat vector of access leakage that the application used. To help identify, let’s take a look at how the application was developed and deployed.
Based on the common SDLC above, we can draw the following threat vector.
Development Workstation Compromised
When a software engineer is working on application development, they often require testing staging and production resources. Debugging situation is happening all the time in the digital native business. In that situation, the engineer also requires accessing production resources. At the end of the day, the engineer’s workstation stores several credentials in the form of a certificate, DB connection strings, and API token.
In the event of the workstation compromised, the attacker can retrieve the essential credentials and can conduct further malicious action.
Hardcoded Credential
In most the development team, git is the most common code repository. It helps to share one developer code with another easily. If that developer is doing a hardcode, it also shares the hardcoded credential. Adding a threat of internal malicious access usage.
The case of accidentally publish code repositories to the public is quite common these days. The company lost the source code, but it also gives away access to its system via hardcoded credentials in its code repository.
Deployment Tool Compromised
CI/CD is a standard procedure in the most current development team. Those deployment tools help them to deploy new features faster. It works by building the application, deploy the artifact in the target server, supply the credentials, and start the application.
Popular CI/CD tools like Jenkins and CircleCI have a native feature to store the credentials. In terms of effectiveness, this is awesome. From the perspective of security, this practice is against the least privilege and segregation of duty concepts. The one that manages deployment operation also manages the credentials. Most CI/CD tools do not have adequate security measures like RBAC and audits. While it’s no doubt that CI/CD tools are super crucial to a digital-native business’s rapid growth, it’s not the best tool to manage the credentials.
Production Server Compromised
When an application is running in production, it must have credentials to access dependency resources. Developers have limited choice to store the credentials. The options are credentials on file, credentials on OS variable, and inject into the application binary. None of those are fully protected when threat actors already have access to the server.
Threat Analysis
In all stages of SDLC, the threat of access leakage exists.
To qualification the threat surface, we can present the threat in the following heatmap.
Credential Storage Solution
Credential storage is a system that stores a set of data securely. The data is usually credential access to other resources such as DB and third-party API Token, but it can store simple user-passwords and complex certificates. Credential storage will interact with other applications like a customer-facing application or an internal enterprise application. It will supply other applications with credentials required by them to operate appropriately. This approach helps transfer the threat to manage the application credentials to the Credential storage system.
A running Credential Storage system can serve multiple applications. This flexibility allows different applications to retrieve the only credentials required by them.
Interaction with the credentials as object data is following the AAA model.
- Authentication
- Authorization
- Accountability
Proper configuration of Credential Storage with the AAA model will reduce the threat of access leakage transferred from the other application.
Credential Storage as a dedicated system itself -by nature- has a threat vector that needs to be addressed. This system will be the core system of the company environment. Credential Storage implementation must adhere to the security CIA model.
- Confidentiality
- Integrity
- Availability
Credential Storage Vendor
Harsicorp Vault
Vault is an open-source project from Harsicorp. Anyone can set up the Vault system in their environment as a Credential Manager. Given this project’s public-license nature, Vault is popular with the developer team, who is starting to level up their security game.
Check https://www.vaultproject.io/ for more info.
AWS Secrets Manager
Secrets Manager from AWS is a SaaS-based solution to store credentials. Having a system running in the cloud allows us to transfer operation effort — effectively release the CIA model requirement. Billed by the number of keys and number of requests, the AWS Secrets Manager is cost-efficient.
Check https://aws.amazon.com/secrets-manager/ for more info.
GCP Secret Manager
Google Cloud Platform (GCP) offers SaaS-based Credential Storage named Secret Manager. With a full cloud advantage in operations, Secret Manager is very cheap.
Check https://cloud.google.com/secret-manager for more info.
CyberArk Conjur
Conjur is open-source Credential Storage from Cyberark. It has an enterprise version to support enterprise companies that do not have the resources to self-manage the open-source version. The enterprise's name is CyberArk Application Access Manager.
Check https://www.conjur.org/ for more info.
Implementation
Credential Storage is implemented in the same application ecosystem. The system access and policy are managed by Security Ops to allow specific applications to fetch the credentials. Each application has a particular path to separate the credential between the application. The idea is to ensure the application or user only able to read credentials designated for them. Application and user require to present the authentication when accessing credential storage.
As a metamorph of this implementation, we can imagine how we leave our house locked when we go out. We have many valuable assets in our place, but it’s not making sense to carry all of the assets whenever we go. The intuitive thinking is to lock the house and hold the key with us.
Now, back to technical thinking. We can verify the implementation using a threat heatmap. Adding Credential Storage in our ecosystem. Storing many essential data, Credential Storage is an entity with a lot of threat surfaces.
To a smaller team, the Credential Storage benefit may not offset the implementation and operation effort. That’s a true statement because, by nature, Credential Storage is transferring the threat. To the bigger team running a dozen applications, Credential Storage is crucial to control the threat hotspot. Also, team security can focus on protecting critical assets — the Crown Jewels.
Technical Control
Credential Storage itself is just a tool. It requires proper configuration to ensure an adequate security posture with AAA.
- Create a robust authentication method for the user and service to manage credentials. Most credential storage vendors have this capability but it’s the user's responsibility to configure it properly.
- Follow the least-privilege principle for user and service access roles. By having clear visibility of “who can do what” and translate it to the system RBAC, we can prevent illegal activity.
- Real-time stream audit log for event monitoring and auditing purpose. Log retention is out of scope from the credential storage system. We properly set up the log backup to ensure the availability of information for future audits.
Administrative Control
A tool cannot run by itself without a policy to support the usage.
- Create a role-matrix to define the object interaction behavior. Creating least-privilege RBAC in the system only possible if the policy of the organization is defined. This policy is a collaboration of HR department and IT department to ensure all role is governed.
- Prohibition to distribute any credential in any media. We can have better threat control with credential storage. But, research suggests that human is the weakest link in the security posture. If one of the employees ever distribute the credential using an external communication channel, we cannot guarantee the secrecy of that credentials.
- Strict policy to keeping and transferring master key. The nature of credential storage where any data is encrypted is wonderful security control. However, there is a concern regarding who has the key and how to store it. More importantly, if the key holder is no longer in the company, there must be a policy to renew the master key.
Verdict
Credential Storage is a perfect solution to control access leakage threats. It’s an essential tool for a team that manages a lot of services to keep the threat heatmap sane.
