Managing and Mitigating Risk: A Cybersecurity Approach Using Identity-Based Access Controls and Secrets Management

In the current fast-evolving threat landscape, organizations face many challenges when managing and mitigating risks to their data. Cyberattacks come in many different forms from threat actors, both internal and external to organizations. But how can the risks of such attacks be managed and mitigated? 

The CIA Triad 

It’s a good idea to understand the types of risks associated with information security. The CIA triad (short for confidentiality, integrity, availability) has long been accepted as the pillar upon which cybersecurity strategies should be built. The three principles of this triad are: 

1. Confidentiality – Protecting information and sensitive data from unauthorized access or disclosure. For example, preventing sensitive data from being stolen and published on data leak websites. 

1. Integrity – Protecting data and information from unauthorized or malicious manipulation. An example of this is preventing malicious actors from altering bank account balances. 

1. Availability – Ensuring that information and data is available when needed, to authorized entities. For example, preventing denial of service (DDoS) attacks. 

The table below shows some common threats and which pillars they are related to:  

Risk Identification 

Almost all risks an organization will encounter begin with a vulnerability of some kind. Whether this is hard-coded secrets in source code or misconfigured access controls. Attackers aim to identify these vulnerabilities to exploit them. Exploitation can come in many different forms, from credential theft to data theft. 

To implement a robust risk management strategy, organizations should look at their core business value, which in most cases will be their data. The vulnerabilities will mostly lay in how this data is accessed and handled, whether that’s user access or machine access. Whilst there are several areas where vulnerabilities can stem from, this blog will focus on those centered around credentials and identity. 

A Credential Audit 

A good starting point for identifying these vulnerabilities is to document all credentials used to access the data. It’s also a good idea to document where these credentials exist and who/what consumes them. Undertaking this exercise will create a solid foundation upon which to build your risk management strategy. These credentials represent identities, and best practice dictates that they should not be shared amongst users and systems. Identifying instances where credentials are shared should also form part of this exercise. Some tools can assist with this by scanning your environments for secrets and providing detailed reports.  

A Network Access Audit 

Network access to systems that store the data is the opposite side of the same vulnerability-coin. Having a clear understanding of how users connect to these networks is just as important. Vulnerabilities often appear in this space too. For example, lack of controls to govern which users can access different systems on the network. This is a common vulnerability with bastion host and VPN implementations. This is because most of these solutions do not take a zero-trust approach to identity and access control. It’s a good idea to document which users and workloads require network access to data housing systems. 

Risk Management and Mitigation 

Identity 

Identity should be the core building block used to mitigate the identified risks. From a human perspective, user identities are a prime target for attackers. Whether it’s phishing attacks or brute force attacks. Malicious actors will attempt to steal the identities of human users to access systems containing sensitive data. A common approach to mitigate this threat is to mandate multi-factor authentication (MFA) for all user accounts that may need access to data-storing systems.  

It’s important to choose an identity provider (IdP) that supports this capability. Centralizing your identity management into a single provider simplifies the management overhead. Management complexity can easily manifest itself as a vulnerability. For example, if identity were to be spread across multiple platforms, any incident that required an identity to be blocked would need to happen in several places. This increases the chance of an operator neglecting to block/revoke the identity in all places, whether that be via forgetfulness or lack of knowledge of all places where the identity resides. 

In the spirit of simplified management, managing users at scale is best done by organizing them into groups of related organizational personas (user groups). For example, you would have a group for developers, who only need basic user permissions, while the operations admins who manage the system would be a separate group with broader access. This will help greatly with managing access controls, which will be covered later in this article. 

Secrets management 

Secrets are often the keys to your data and infrastructure, and as such, should be managed with great care. They should be stored centrally to offer a single source of truth. Different types of secrets may need to be managed: 

1. Static secrets – These could be long-lived tokens for a third-party API for example. 

1. Ephemeral/dynamic secrets – These secrets are generated on demand and expire after their time-to-live (TTL) setting has been reached. 

1. Sensitive application data – This could be personally identifiable information (PII) within your application. 

Depending on the types of secrets you have in your estate, you should ensure the platform you choose supports the type of secrets you consume. For example, if you have sensitive application data, it’s a good idea to choose a platform that offers encryption as a service.  

You should also ensure that any static secrets are rotated regularly. This is one of the benefits of having a centralized secrets management system. It acts as a single source of truth for the entire organization. That means one place to go to for audits, updates, rotations, or emergency revocation. 

The secrets management platform is your gateway to your secrets and as such, should be tied to your IdP. As mentioned before, identity should be managed centrally rather than be duplicated into different platforms such as this. To achieve this, the platform you choose should have the ability to delegate user authentication to your IdP using workflows such as OAuth 2.0. 

As well as storing secrets, it’s important to have visibility on when secrets have been accessed, changed, or otherwise interacted with. This is especially important in regulated industries where audit and compliance concerns exist. In the event of an audit or a security incident investigation, it’s essential to know Who accessed What and When this occurred. Having a robust and flexible logging system will provide this information. Your chosen secrets management platform should include this functionality. A related consideration is a potential requirement to feed these logs into a security logging system in real-time. This provides the ability to perform automated anomaly detection and alerting of unusual or unauthorized access. 

Access Policies 

Whilst identity is concerned with authentication (AuthN), this offers limited value without robust access policies. These will govern which entities are authorized (AuthZ) to access data and resources.  

To get started, map out different roles that your users fit into. These roles will be specific to your organizational structure. For example, an organization may have a team of data scientists that need read access to a data warehouse and another team of platform engineers that need access to a cloud platform. Mapping out these different roles will help with implementing role-based access controls (RBAC).  

This is closely related to the user group strategy mentioned previously, though there could be multiple roles for each group. The reason for multiple roles is when deciding which users should have access to different data and resources, it’s best practice to apply the principle of least privilege access. This is a practice whereby users only have access to the data and resources they require to perform their respective functions.  

For example, a team may consist of developers and SREs, where the developers require access to databases and message queues, and the SREs require the same access plus access to the cloud platform. The SRE access could even be broken down further if required. For example, they may only need access to particular parts of a cloud platform. 

Once these roles have been mapped out, the process of policy writing can begin. It is best practice to implement a default deny strategy where access isn’t granted to anything without AuthZ. This is an intentional way of writing policies that limit the chance of unintended access being granted to unauthorized entities.  

Policies should be written anywhere that governs access to data and resources in your workflows; however, a centralized approach to this where possible will again simplify its management. For example, you could mandate that credentials to access all data and resources go through your chosen secrets management platform. This would mean that all policies can be written there. 

Machine-to-Machine Network Access 

Another key vulnerability is machine-to-machine communication. Whilst much of this article has focused on human-centered vulnerabilities, machines (workloads) that need to communicate with other workloads to perform their functions provide a significant attack surface. The principle of least privilege access should also apply here from a network communication perspective.  

Without this, malicious threat actors, whether internal or external, could manipulate an existing workload or deploy a rogue workload to obtain sensitive data (assuming they have stolen credentials with the correct access levels) and stream it to a location of their choosing, thereby compromising the confidentiality of the data. They could also use this approach to manipulate data, which compromises the integrity of it. 

To mitigate these threats, it’s a good idea to implement a service mesh that has support for your underlying platforms, whether you run workloads on bare metal servers, virtual machines (VMs), or containers. The service mesh should include the ability to authenticate and authorize workloads before they are allowed to communicate with each other, and in which direction such communication can flow. 

Human-to-Machine Network Access 

As mentioned earlier, common human-to-machine network access approaches such as bastion hosts and VPNs tend to have vulnerabilities because they do not implement a zero-trust approach. This means that once a user is on the network, they are sometimes trusted to connect to anything within the network perimeter. This creates a risk of malicious internal threat actors accessing and/or manipulating systems and data without authorization. There is also a risk that if an external threat actor can breach your network perimeter, they would have unrestricted access to systems and data on the network.

To mitigate against this, you should implement a platform that uses identity as the core construct for governing network access. Rather than just place users within the network perimeter, it should also govern where within the network the user is authorized to access. Similar to secrets management platforms, it should include the ability to delegate user authentication to your IdP using an approach such as OAuth 2. 

A more mature model is to choose a platform that natively integrates with your secrets management platform. This would allow credentials to be injected into authorized user sessions. Furthermore, access control policies for users could be moved here as the centralized single source of truth. 

From an audit and compliance perspective, this platform should include extensive logging capabilities. In addition to this, it should also possess the ability to record sessions. 

Summary 

Getting started with implementing an information security risk management strategy is not a one-size-fits-all all task. There are several considerations to take into account. With that said, there are some industry best practices and guidance that can help you along the way. These can be broken down into the following: 

1. Conduct a thorough threat assessment of your estate. Document all credentials, secrets, sensitive data and any vulnerabilities that exist in your estate. You can use secrets scanning tools to help you discover any sensitive information within your estate. Be sure to consider the CIA triad as you assess potential vulnerabilities. 

1. Centralise identity management. 

1. Use a single IdP for your user management. 

1. Create user groups based on organizational structures and place users in their respective groups. 

1. Ensure your chosen IdP can facilitate delegated authentication using workflows such as OAuth 2. 

1. Mandate MFA for all users. 

1. Implement RBAC approach to policy authoring. Tie this in with user group management. Where possible, centralize your access control policies to simplify the management overhead. Ensure access policies are regularly reviewed. 

1. Use a centralized secrets management platform. Ensure you choose a platform that integrates with your chosen IdP and has support for the types of secrets identified during the threat assessment. This should be your single source of truth for secrets. Rotate static secrets regularly to reduce the attack surface. Where static secrets exist, evaluate whether or not they could be graduated into dynamic secrets as your strategy matures. 

1. Implement a service mesh solution. Choose a platform that supports your underlying hosting platform (bare metal servers, VMs, or containers), and ensure it can control which workloads can communicate with each other. This will allow you to simplify your network routing rules. 

1. Implement an identity-based human network access platform. Ensure your chosen platform integrates with your chosen IdP to delegate user authentication. Write robust access policies to this platform using the same RBAC approach mentioned earlier. Choose a platform that has audit and compliance capabilities, from logging to session recording. For additional value, choose a platform that natively integrates with your chosen secrets management platform. 

Centering your strategy around identity will give you the best possible chance of success. Following this guidance will get you started. 

KubeCon + CloudNativeCon EU 2025 is taking place in London from April 1-4. Register now.