CI/CD audits conducted in 2025 and 2026 revealed that credentials leaked in repositories, misconfigured runners, insecure artifact stores, and overly permissive cloud roles are all vectors attackers can chain to gain persistent, high-privilege access across the entire infrastructure.

A high-level overview of DevOps tooling is illustrated below:

A compromise at any stage of the pipeline can provide a path toward more sensitive systems.

This article walks through a representative CI/CD attack kill chain based on observed real-world patterns, highlighting the most commonly exploited vectors and the key hardening measures to reduce the attack surface at every stage of the pipeline, from source code to production deployment.

The Kill Chain: from reconnaissance to persistence

Reconnaissance and Initial Access

The kill chain typically begins with a phishing targeting developers to harvest credentials and MFA codes, though MFA itself can be bypassed through token hijacking or session theft.

It should be noted that credential compromise alone is not always sufficient to directly access sensitive administrative portals. Security controls protecting Microsoft 365 administrative interfaces have been strengthened through the implementation of MFA and, where applicable, Conditional Access policies, limiting the impact of phishing on highly privileged access.

However, in modern enterprise environments where most business applications rely on Single Sign-On (SSO), the compromise of a Microsoft session (e.g., through session cookie theft) can provide attackers with access to a wide range of interconnected services, including code repositories and CI/CD platforms. Attackers typically use this initial foothold to identify development environments and establish persistence through mechanisms such as Personal Access Tokens (PATs).

A common but often overlooked risk arises when user accounts are disabled at the identity provider level (e.g., Entra ID) but not fully deprovisioned within repository platforms. In such cases, previously issued PATs may remain valid, allowing attackers to retain repository access despite account revocation.

Additional entry points include the exploitation of known CVEs and poor credential hygiene. Many major vulnerabilities in DevOps tools are regularly discovered, highlighting the need for continuous vulnerability management. Exploiting a critical vulnerability can directly provide privileged access to a tool in the chain.

Examples include:

• CVE-2024-23897 (Jenkins), which allows unauthenticated attackers to read arbitrary files on the Jenkins controller file system, leading to exposure of sensitive secrets,
• CVE-2023-7028 (GitLab), in which user account password reset emails could be delivered to an unverified email address,
• CVE-2023-36561 (Azure DevOps Server), an elevation of privilege vulnerability allowing attackers to gain unauthorized access to functionalities within Azure DevOps Server, with potential impact on pipelines, secrets, and project-level resources.

REMEDIATION – Strengthen Access Controls for Source Code Repository

To mitigate initial access risks, organizations should implement controls to prevent unauthorized access, detect persistence, and enforce strong identity governance.

Enforce confidential access policies and network exposure

• Avoid the use of generic or shared accounts,
• Use dedicated developer identities separated from standard productivity (email and office) accounts to reduce exposure to phishing attacks and limit the impact of credential compromise in CI/CD environments.
• Enforce phishing-resistant MFA mechanisms (FIDO2 keys, certificate, etc.),
• Implement Conditional Access policies to restrict access based on contextual factors such as network location and device compliance.

Implement mechanisms to detect persistence attempts

• Implement monitoring mechanisms to detect suspicious creation or usage of PATs in GitLab, anomalous activities such as deployments occurring at unusual times, etc.
• Monitor the addition of new authentication methods in Entra ID, as a potential sign of compromise, particularly passwordless ones, after a phishing event.

Recertify all accesses periodically and remediate unused accounts

• Disable or remove unused or inactive accounts,
• Revoke access for offboarded employees across all systems,
• Conduct periodic access reviews, at least every six months for high-risk users.

Code Repository and Pipeline Compromise

Source code repositories are often directly integrated with CI/CD pipelines, meaning that changes to the codebase can automatically trigger build and deployment processes. As a result, compromising a developer account can influence how applications are built and deployed.

To reduce the risk of unauthorized changes reaching production, organizations typically protect production branches (e.g., main or master) through pull requests, approvals, and automated validation checks. In contrast, development branches are generally less strictly controlled to support faster development and testing.

In the observed scenario, the attacker targets the development branch and modifies the pipeline configuration file (gitlab-ci.yml), injecting a malicious command (aimed at establishing remote access) into an existing job. When the pipeline is executed, this command runs on the CI/CD runner, allowing the attacker to gain remote access to it.

As part of the compromised CI/CD environment credentials, the attacker gains access to a Nexus token, which is an artifact management system, used to store and distribute trusted build artifacts consumed by downstream pipelines.

REMEDIATION – Harden Code Repository Security Controls

Securing the code repository is essential to prevent attackers from abusing CI/CD pipelines after initial access, as repositories directly control how code is built and deployed.

Harden code repository to limit pipeline triggers

• Configure protected branches on the branches used for deployment,
• Set up multi-level approval workflows on merge requests that trigger pipelines and disable self-approval,
• Use code ownership to assign and require approval from designated owners on sensitive files (e.g. CI/CD job configuration).

Limit project visibility and permissions

• Limit writing permissions to only those who require them for their role,
• Restrict project visibility based on the need-to-know principle, using internal or private (preferred) visibility.

Establish proper secret management hygiene

• Configure scoped CI/CD secrets the project level and prefer ephemeral credentials whenever possible,
• Detect secrets in clear text as early as possible (at commit time or before code is pushed) and revoke immediately if exposed,
• Conduct periodic reviews (e.g., internal audits or red team exercises) across platforms such as Git repositories, Jira, or Confluence to help identify previously undetected leaks.

REMEDIATION – Strengthen Self-Hosted Runner Security Controls

Runners are critical components of CI/CD pipelines, as they execute code and handle sensitive data. If compromised, they can be used to move laterally, access secrets, or take control of the environment.

Restrict network exposure and execution scope

• Restrict runner network traffic to only what is required for pipeline execution, and enforce network controls such as proxies and segmentation to prevent unrestricted internet access and limit lateral movement within internal networks.
• Restrict pipeline triggers from untrusted or personal repositories.

Treat runners as sensitive systems

• Treat runners as critical servers (regular OS patching and hardening),
• Deploy Endpoint Detection and Response (EDR) solutions for process monitoring, including within containerized environments.

Use dedicated and ephemeral runners

• Prefer dedicated runners per project or environment. Sharing runners across multiple contexts increases the risk of cross-project contamination and privilege escalation,
• Use ephemeral / autoscaling runners that are destroyed after each job,
• Ensure VM-based runners are also ephemeral and isolated to ensure no residual data or access persists between executions. In addition, rely only on hardened and trusted base images (e.g. golden images for VM-based runners and approved container images), to prevent execution in compromised or unverified environments.

Secure container-based runners

• Allow only approved and trusted images in pipeline executions to prevent the introduction of malicious code through compromised or unverified images,
• Apply least privilege in container runtime environments,
• Avoid privileged mode and drop unnecessary Linux capabilities,
• Use secure build engines (BuildKit / Buildah) when Docker-in-Docker is required

Harden Cloud-based runners

• When using cloud-managed runners, enforce isolation and identity scoping, restrict metadata access to prevent credential exposure from underlying infrastructure, and ensure CI/CD roles are governed by strict least-privilege IAM policies to avoid excessive permissions.

Artifact Poisoning and Dependency Attacks

In software delivery environments, artifact management systems store and distribute outputs generated by CI/CD pipelines. These outputs, known as artifacts, represent the packaged results of the build process, such as compiled binaries, application packages, or deployment images.

Artifacts are stored centrally to ensure versioning, traceability, and reuse across multiple pipelines. In addition to application-specific outputs, these repositories often also host shared components such as golden images, reusable libraries, or common runtime dependencies. Because they originate from trusted build processes, artifacts are typically assumed to be safe and are widely consumed by downstream pipelines without additional validation.

In the observed scenario, the attacker uses previously obtained credentials to authenticate to the artifact repository (Nexus in this example) with excessive permissions (read/write across multiple categories, rather than being limited to a single application scope), and gains access to both production-grade and shared artifacts.

Among these, the attacker identifies a legitimate Terraform binary used within the infrastructure deployment process (referred to as the tofu binary), which is commonly trusted and consumed by downstream CI/CD pipelines to provision and manage cloud resources.

The attacker downloads this artifact locally and modifies its contents by injecting malicious logic while preserving its original functionality, and embeds hidden behavior designed to interact with AWS Identity and Access Management (IAM) and AWS Security Token Service (STS) services to retrieve credentials.

The modified binary is then reuploaded to Nexus, replacing the legitimate version with a poisoned artifact.

From this point onward, any CI/CD pipeline consuming the artifact automatically retrieves the compromised binary as part of its dependency resolution, as it’s still considered trusted.

Upon execution, the poisoned binary activates the embedded malicious payload, which is designated to retrieve the AWS access token used by the Terraform execution context and send it to the attacker-controlled server for exfiltration. It then generates an obfuscated output encoded in Base32. Decoding allows reconstruction of a JSON object containing AWS credentials (AccessKeyId, SecretAccessKey, and SessionToken).

The attacker configures these credentials locally and uses AWS STS (GetCallerIdentity API call) to confirm identity impersonation of the CI/CD runner. 

This illustration shows the attack chain: artifact compromise, injection of malicious logic, propagation through CI/CD pipelines, and eventual AWS credential theft leading environment compromise.

As a result, the attacker gains unauthorized access to AWS resources under the guise of a legitimate identity.

REMEDIATION – Improve Artifactory Access Management Controls

Artifact repositories such as Nexus are key CI/CD components used to store and distribute build dependencies and artifacts. They are high-value targets for supply chain attacks.

Security requires strong access control, dependency governance, and continuous integrity monitoring.

Harden the artifact repository platform

• Allow wide read on repository only at two conditions: from needed service (CICD) and if password management in dependency exist,
• Highly restrict writing permission,
• Change default

Perform Software Composition Analysis (SCA)

• Apply Software Composition Analysis to both internal dependencies (stored in local repositories) and external ones (retrieved from remote or proxy repositories) to detect known vulnerabilities and outdated components.

Restrict artifact sources

• Maintain a whitelist of trusted repositories to ensure only approved sources are used,
• Enforce repository-level controls to exclude unapproved or vulnerable versions, for example in Nexus, or through exclusion rules in JFrog Artifactory,
• Prevent CI/CD pipelines from accessing untrusted external sources by enforcing strict repository boundaries.

Cloud Compromise via CI/CD Workload Abuse

In cloud environments, CI/CD runners are typically assigned privileged IAM roles to perform deployment operations, including creating, modifying, and deleting infrastructure resources. These roles often include broad permissions such as AdministratorAccess or overly permissive custom policies, enabling the runner to interact with a wide range of AWS services including compute, storage, and identity management.

When a CI/CD runner is compromised, an attacker can directly abuse these privileges without requiring further escalation. This can lead to immediate access to sensitive resources such as S3 buckets or RDS databases, enabling data exfiltration. The attacker may also leverage IAM permissions to assume additional roles across other AWS accounts or projects, facilitating lateral movement within the organization. In addition, access to compute-related services can be abused to deploy, modify, or persist malicious workloads, ultimately resulting in a full compromise of the cloud environment.

From developer compromise to Cloud takeover: full CI/CD attack path overview

The CI/CD attack chain starts with the initial compromise of a developer and ends with the full takeover of the cloud environment.

The following illustration highlights key detection and monitoring opportunities across the CI/CD ecosystem. It shows how security telemetry can be collected and correlated throughout the different stages of the CI/CD attack chain, from development activities to CI/CD runners, artifact repositories, and cloud IAM operations.

Overall, although CI/CD pipelines significantly expand the attack surface, they also provide multiple strategic interception points where centralized logging and security monitoring can enable early detection and response to malicious activity.

In conclusion, to achieve a secure CI/CD pipeline, security must be considered end-to-end, from developers’ environments to production systems.

Developers are the first link in the chain, and securing their accounts is essential. This should be supported by good practices such as secure secret management and regular security awareness.

It’s also important to ensure proper isolation between environments and to enforce strict least privilege for both users and service accounts.

Security issues cannot be fixed by small patches if the overall pipeline design is weak.

Finally, deployment use cases should be clearly defined from the start, as they directly drive the architecture and IAM design choices.

Beyond these technical measures, CI/CD security must be continuously assessed through regular technical audits as well as organizational reviews of the development lifecycle to ensure risks remain under control as the environment evolves.

For a broader perspective and higher-level recommendations on positioning CI/CD as a cornerstone of the information system, see the RiskInsight article: “CI/CD: the new cornerstone of the information system”.

Cet article CI/CD Security: Supply chain attack from a compromised developer est apparu en premier sur RiskInsight.

Is the tiering principle promoted for on-premise infrastructure applicable to the cloud?

Evolution of the Security Model

In on-premises Active Directory environments, infrastructure security generally relies on strict segmentation into three tiers (T0, T1, and T2). This allows for the isolation of critical administration systems (T0), servers (T1), and user workstations (T2) in order to limit propagation risks.

This hierarchical and perimeter-based organization is inherent to the AD world and cannot be directly applied to the cloud for the following two main reasons:

• Portals are centralized: A wide variety of administrators with different rights.
• The boundary between administration levels is more complex: The principle of granular permissions, whether Role-Based (RBAC), Attribute-Based (ABAC), or conditional (location, risk, compliance, authentication methods, etc.) allows for very precise access configuration, but it complicates and obscures the global view of permissions.

To address this new paradigm, Microsoft published its Enterprise Access Model (described here), highlighting three main planes: the Control Plane, Management Plane, and Data Plane.

This model retains “cascading” criticality but simplifies it with:

• the 3 tiers into 2 access types: administrator vs. user;
• the administration flows into portal access;
• the server’s criticality is centralized within the Data plane.

Below is a comparative illustration between the old and the new model:

This new model particularly highlights 3 elements:

• User identity: privileged access vs. user access;
• Data and services: at the expense of servers;
• The method of access to web administration portals.

The inversion of importance between “servers” and “web portals” abstracting Active Directory is a radical change.

However, very few (if any) large organizations are at this stage of abandoning their “legacy” IS; a large part will be in a transitional state where the information system has been virtualized on a cloud in order to move away from its datacenters, but whose administration methods have remained the same.

These companies must deal with an obsolete tiering model and an Enterprise Access Model disconnected from current security risks and needs.

For the remainder of this article, we will take as an example the Tartampion company, which has just completed a 3-year Move-to-Cloud program on AWS. The outcome is as follows:

• A Landing Zone was created, applications already on AWS were integrated into it
• Given the lack of time and resources, a major part of the IS was incorporated via lift and shift, including business, network, bastion, and AD solutions.
• The Data Centers were closed

A problematic hybrid and virtualized IS

According to the EAM, Azure and AWS portals are displayed at the same level (the management plane) at the T1 tier, without any other form of distinction. However, these 2 cloud environments are in themselves the support for numerous IS, used by multiple collaborators with very varied levels of rights and impacts.

To illustrate the previous points, let us set aside the Digital Workplace aspect (O365 suite) and take 3 AWS accounts from a Tartampion Landing Zone, supporting different infrastructure services:

Based on the framework proposed by Microsoft, these three AWS accounts should belong to the Management plane with a T1 security level. However, in the event of a compromise of one of the 3 accounts by an attacker, the impacts would be very different.

If the Landing Zone is correctly implemented, the compromise of a Sandbox account would have very little impact, whereas that of the Master Account would lead to the compromise of all underlying accounts and resources.

A more adequate example of segmentation would be the following:

Microsoft’s Enterprise Access Model is a macroscopic framework that allows for initiating a baseline for cloud service segmentation, but which remains to be adapted according to the criticality of the concerned IS.

How can it be made relevant? To answer this, it is necessary to understand the attack scenarios exploiting cloud services.

The cloud from an attacker’s perspective

5 cloud principles facilitating attacks

Firstly, public cloud administration panels are exposed to the Internet by default, unlike sensitive IS resources. Thus, successful phishing very likely leads to access to the cloud.

Secondly, companies today have hybrid organizations (on-premise and cloud):

• Cloud infrastructures are connected to the rest of the on-premises IS;
• Workstations can also be hybrid and managed by a cloud service like Intune. Permissions to use this service are managed in Entra ID;
• Identities are often synchronized accounts, this also applies to administration accounts.

Hybrid organizations can facilitate lateral movement between the cloud and on-premise environments.

Thirdly, identity management is very complex with different scopes. For example, Entra ID allows managing access to Azure and M365 for users, as well as for applications and service accounts.

In addition, cybersecurity concepts related to the cloud are still relatively new and unfamiliar to certain “legacy” teams, such as the SOC/CERT, network, etc. The most sensitive cloud resources are not systematically identified, protected, and monitored.

Finally, even if native detection mechanisms are present, they are not always interconnected with SIEM/SOAR, which slows down response capabilities. Moreover, a recent Purple Team operation conducted on Azure and AWS infrastructure confirmed that native detection tools have limited detection capacity. This is an observation also found in Red Teams since, with an “OpSec” approach, cloud detection tools are rarely able to identify an ongoing attack.

Feedback from our penetration tests & Red Team

Derived from recent Red Team operations, these cloud-specific attack paths demonstrate the impact and the ease with which it is possible to escalate privileges to obtain highly permissive access:

The first scenario, carried out on AWS, is described below; the other two were analyzed in a series of Risk Insight articles available here.

Reconnaissance and Initial Access

Categories of employees are generally targeted in order to compromise a person with interesting rights in the IS (Developer, Support, OPS…). A frequently used method is phishing. Current phishing mechanisms can bypass the use of complex passwords and most MFA (Multi-Factor Authentication) methods.

Privilege Escalation and Lateral Movements

In the first scenario, a compromised developer possessed access to a Citrix farm. Citrix environments are not simple to completely harden, and a few breakout vulnerabilities allowed the Red Team to gain access to the underlying server.

Information gathered on the machine indicated that the server could be hosted on AWS. This was verified by trying to access the server’s AWS metadata: the instance had rights on the client’s AWS account. The Citrix virtual machine possessed the “AmazonEC2FullAccess” role allowing it management actions on EC2s in the same AWS account.

Using the AWS CLI, the other EC2s were listed. A Domain Controller was present in this AWS account. It is a common practice to regroup services intended to be used by several projects into a single account, generally called “Shared Services”. It is nevertheless recommended to verify that the criticality of shared services is homogeneous to be able to apply adequate hardening on the account or separate them into several environments.

Actions on trophies

From the Citrix server AWS role, a snapshot of the domain controller was taken and then downloaded. Domain controller backups contain all the machine’s files, including the most sensitive files like the ntds.dit database, which contains the information and secrets of all domain users. The exfiltration of this database translates to the total compromise of the concerned AD domain.

This scenario illustrates one of the attack paths that were exploited during Red Team operations, facilitated by the lack of visibility regarding the impacts that a compromised resource hosted on the cloud can have.

Faster and stronger impacts

Attacks already possible on an on-premises IS can be reproduced and even accelerated thanks to cloud features. For example, the encryption of S3 buckets (file storage service) using a KMS (encryption) key from another AWS account mimics massive data encryption, or the use of the “lifecycle” feature allows for the deletion of all objects in less than 24 hours, regardless of the amount of data.

New attacks have also appeared, such as “Subscription Hijacking” which allows transferring an Azure organization’s subscription to another and thus stealing all the data it contains while preventing remediation actions. This attack is achievable in a few clicks from the Azure web interface.

Identification and protection of the cloud trust core

Identification

The trust core adopts an approach focused on asset prioritization, which differs from the tiering model or Microsoft’s Enterprise Access Model. Unlike these models which offer a predefined segmentation, there is no universal grid: each organization must identify for itself which resources deserve the highest level of protection. The idea is to establish a restricted circle of critical resources (whether cloud or on premises) and then deploy decreasing levels of protection as one moves away from this core.

The identification of the trust core relies on two main criteria:

• Business Criticality: these are the resources that concentrate the value and business continuity of the company. If they were to be lost or compromised, the consequences would be immediate for daily operations and financially. A SharePoint environment containing intellectual property / patents is a common example;
• IS Criticality: these are the resources that ensure the administration of the information system and which possess a high level of access. Their compromise would have a major impact on the entire IS and would allow for the business impact previously mentioned. Here we find domain controllers or cloud IAM services like Entra ID and AWS Identity Center.

This mapping is never totally clear-cut. For certain elements, the posture to adopt remains vague; two examples illustrate this well:

• EDR: an obvious security element of an IS, systematically deployed on both workstations and cloud and on-premises servers, its administration console is increasingly exposed to the internet, and allows executing arbitrary commands on the devices equipped with it.
• CI/CD pipelines: a clever but complex agglomeration of applications calling each other, whose access (the code repository: GitLab, GitHub…) is accessible by all collaborators and the runner permissions are very often administrator over the entire cloud infrastructure. Out of all Red Teams conducted in 2024 & 2025, 80% exploited vulnerabilities associated with these solutions to progress in their operation or even obtain compromise trophies through these means.

In order to identify the center of the trust core, which we will call the security foundation, we can revisit the precepts of the old T0: the compromise of one of its elements would probably lead to that of the others, and by cascade, of the major part of the IS.

Assuming that your applications apply correct inter-user segregation (all of your SharePoint sites are not accessible by everyone, are they?), references to the next applications should be understood as administrator / super-user access to them, and not simple user.

Here is one possible representation of a hybrid trust core:

In this representation, on the on-premise side, we can observe:

• The T0, with its domain controllers, ADCS, and potentially the PKI, the bastion, the EDR console…
• The T1, integrating additionally high-impact business applications.

And on the cloud side, we find:

• At the core, the Control Plane (AWS Orga & Identity Center, Entra ID) as well as the Landing Zone modules supporting T0 (if part of T0 is hosted in the cloud);
• Moving outward, the various administration consoles for productivity suites, and for infrastructure or application management.

When establishing this diagram, it is important to keep in mind that:

• IT serves the business, and even though the central zone of the trust core is mainly occupied by technical components, critical solutions should be included;
• Dependency/compromise chains have a significant impact on architectural choices: positioning an AD on AWS, or deploying an EDR on an AD can suddenly create numerous paths for compromise and pivoting between the 2 worlds.

Finally, building a trust core cannot be limited to a static classification logic. It must rely on an approach that evaluates the criticality of each asset and the risk it introduces (a software development company will surely not position its Git at the same level as a civil engineering company).

Protection of the cloud trust core

The security of the trust core will rely on the two traditional risk factors:

• Reduce impact: How to prevent a compromised or malicious user from connecting to cloud portals via a browser and performing sensitive actions in a few clicks, such as backing up a domain controller hosted on a VM or deleting production data backups?
• Reduce probability: How to reduce the risks of illegitimate access from a session cookie stolen via phishing, workstation compromising, or user password reuse?

Protection of the cloud security foundation

Regarding the cloud “security foundation,” it is possible to prioritize environments by criticality according to this macroscopic scale:

Depending on the teams involved and the complexity of including them in a particularly high protection level, some organizations choose to exclude environments whose compromise would not allow for dangerous lateral movement, such as those for FinOps, detection, the Digital Workplace…

Securing the cloud security foundation relies on 2 main points:

• Impeccable hygiene: streamlined IAM configuration, least privilege strategy, deployment procedures, limitation of resources to the strict minimum…
• A passive / active security layer: deployment of policies (SCP on AWS, Policy on Azure) explicitly forbidding certain actions, or the manipulation of certain resources, and detection rules to trigger an alert in the event of a policy modification or the occurrence of one of its protected events.

These policies can be effectively associated with a tagging strategy to apply, in addition to the RBAC (Role Based Access Control) model, an ABAC (Attribute Based Access Control) model.

For example, it is possible to tag different resources with a “tiering” key and a value between “T0”, “T1”, “T2” and then deploy this set of strategies:

• Prohibit any action targeting a resource tagged “tiering” by an identity whose own tiering tag value is not equivalent;
• Prohibit the manipulation of tiering tags, except for a specific role.

And that is how, with a few tags and 2 SCPs, it is possible to replicate the Microsoft tiering model (some exceptions may occur).

Protection of identities and access

To protect users, 3 hardening themes can be implemented:

• Identity: With which account does the user connect to cloud administration interfaces? How are rights obtained?
• MFA: Is the identity protected with multi-factor authentication resistant to phishing attacks?
• Origin: From which platform does the user connect to cloud administration interfaces? Is the platform managed, and healthy?

Several levels of protection are conceivable in order to protect cloud administrators:

To protect the restricted trust core, represented by the triple padlocks, it is recommended to implement the most robust authentication factors. This includes the use of a dedicated account for cloud administration, the activation of physical multi-factor authentication (example: FIDO2 security key), and the use of a workstation specifically reserved for operations on this trust core (this last one is not often implemented).

For resources further from the center of the core of trust, symbolized by the double padlocks, a hardened but proportionate security level can be applied, in order to strengthen protection to control costs and reduce excessive constraints on the users concerned.

Ultimately, the most secure methods are also those that imply the most constraints for the people concerned, usage must be controlled (limiting day-to-day operations) and emergency situations considered.

Repeat Operations

At the end of the identification and protection phases, resources will be distributed across the different layers of the core of trust.

To verify the proper implementation of the core of trust, an audit can be conducted to verify the proper protection of the critical resources that compose it.

An information system is always evolving, but the first two phases will have been performed at a given moment. New critical resources may be added, others modified or even deleted. It is essential to regularly re-evaluate the IS and update the distribution of resources within the core of trust.

In conclusion, information system security now operates within a context of increasing complexity and strong diversification of infrastructure components and services.

In this context, it appears increasingly complex to define a universal security model. Certain frameworks retain all their relevance within well-identified perimeters: tiering remains a reference for securing Active Directory, just like the EAM for cloud environments strongly centered on the Microsoft ecosystem. Nevertheless, these models quickly reach their limits as soon as one moves away from these specific use cases.

For the majority of information systems, an approach based on risk analysis therefore stands out as the most relevant. Identifying a core of trust, clearly defining critical assets – the crown jewels – and deriving security measures from these elements allow for building a more pragmatic security posture, adapted to the reality of the IS and capable of evolving with it. This logic, less normative but more contextualized, undoubtedly constitutes one of the major levers for reconciling security, agility, and sustainability of information systems.

Cet article Cloud Security: Adapting to a new reality est apparu en premier sur RiskInsight.