In this second article, we will analyze practical attack scenarios that threaten the Control Plane and provide actionable recommendations to mitigate these risks. Specifically, we will explore three common attack scenarios that pose significant threats to the control plane: IT Support compromise, Control Plane Administrator Laptop compromise and CI/CD compromise. By understanding these attack vectors and implementing robust security measures, you can significantly enhance your cloud environment’s resilience against potential compromises. 

IT support compromise 

Imagine a scenario where the account of a member of the IT support is compromised. This might occur through a phishing attack, social engineering, or even a credential stuffing attempt. Such accounts often can reset passwords, including those of very high-privilege users, like Application Administrator or an Azure’s Owner at root level, thereby gaining unauthorized access to critical resources from Entra ID to the Cloud to On-premises to SaaS. 

This type of attack illustrates a critical point we discussed in the first article: the need to scope and isolate the control plane effectively. The help desk, while essential for everyday operations, must be rigorously segregated from high-privilege administrative functions. The lack of such separation can allow an attacker to pivot from a compromised help desk account to a Global Admin role. 

To mitigate this risk, organizations must implement a series of strategic defenses: 

• First, isolating control plane accounts from those managed by IT support is essential. This ensures that even if a help desk account is compromised, it cannot be used to access or manipulate high-privilege accounts.  
• Second, using cloud-only accounts dedicated to control plane tasks reduces the likelihood of legacy systems being exploited as an entry point.  
• Third, coupling these accounts with phishing-resistant Multi-Factor Authentication (MFA), Just-In-Time admin (JIT), robust identity governance and conditional access policies, strict workstation conformity creates a multi-layered defense that significantly diminishes the risk of such an attack. 

This scenario underscores the importance of viewing every account as a potential threat vector. By enforcing strict segregation and controls, you can ensure that your control plane remains secure, even if a lower-tier account is compromised. 

Control Plane Admin’s Laptop compromise 

Now, consider a situation where the attacker successfully compromises Intune’s Mobile Device Manager (MDM) admin account. With this access, the attacker gains control over Intune admin portal, allowing him to manipulate the laptop of a control plane admin. He can deploy malicious configurations, install backdoors, or directly connect to the admin’s laptop (Remote Help). This access turns the admin’s laptop into a powerful tool for further exploitation, granting the attacker the ability to execute commands, exfiltrate sensitive data, and manipulate cloud resources without the need for additional sophisticated hacking. 

This scenario reminds us of a key principle from the first article: cloud security must be approached holistically. It is not just about securing identities but also ensuring that the devices used to access the Control Plane are secured. In this case, the Control Plane admin’s laptop becomes a critical asset that, if compromised, could undermine even the most sophisticated cloud defences. 

To prevent such an outcome, organizations need to integrate admin workstations in the Control Plane. At a minimum, devices used for administrative tasks must be tightly controlled through dedicated MDM policies, ensuring strict access controls, encryption, and continuous monitoring. However, for higher-risk scenarios, leveraging Privileged Access Workstations (PAWs) is essential. PAWs are isolated, hardened machines dedicated solely to administrative activities. They operate under a far stricter security regime than standard devices—limited internet access, dedicated management, and enhanced monitoring—ensuring that they cannot easily become a tool for attackers. 

This scenario demonstrates that endpoint security is inseparable from cloud security. By securing the very devices that control your cloud infrastructure, you reduce the chances of a breach originating from compromised endpoints, ensuring that your Control Plane remains protected against even the most sophisticated attacks. 

CI/CD compromise 

As cloud environments rely heavily on automation, CI/CD pipelines for managing infrastructure become prime targets for attackers. Imagine a scenario where an attacker gains access to a DevOps engineer’s account via phishing or credential theft. With this foothold, he pushes malicious Infrastructure as Code (IaC) change into a Git repository, knowing this will trigger an automated Azure pipeline. The pipeline validates, plans, and deploys the infrastructure on Azure, leading to the destruction or alteration of key Azure resources, i.e. the foundations of the Landing Zone. Alternatively, the attacker modifies the Azure Pipeline’s YAML configuration. By doing so, he causes the pipeline to leak a service principal secret in the logs or debug console, which is then used to make unauthorized Graph API calls. Abusing the overprivileged identity, the attacker can escalate its privilege, compromising Entra ID identities or Office 365 accounts. Runners also play a crucial role in the CICD pipeline. They are agents responsible for executing jobs in the pipeline. They can be hosted and maintained by the Cloud Provider or hosted on-premises. As with any server, their compromise can be used as a pivot point to bounce back to the Landing Zone (e.g., token stealing) or other associated services. 

This scenario illustrates interconnectedness of cloud security. The CI/CD pipeline, often seen as a back-office function, is, in reality, deeply integrated with the Control Plane. Its compromise can lead to widespread, devastating consequences to the very foundation of your cloud operations. 

To protect against such threat, it is crucial to isolate the Control Plane’s pipeline whose purpose is to build the Landing Zone from project pipelines. Then, one should apply the principle of least privilege, ensuring that accounts and runners within the pipeline have only the permissions they need to perform their tasks. For example, to limit runner permissions we can use federated identity and request OpenID Connect (OIDC) tokens, which provide scoped and temporary access to Cloud Services like Azure. Additionally, adopting automated security practices such as Configuration as Code (CaC) or Policy as Code (PaC), can help reduce human error and ensure consistent security across your deployments. 

In cloud security, every process and every tool must be viewed through the lens of potential risk. The CI/CD pipeline is no exception. By securing this critical component, you not only protect your control plane but also ensure the stability and security of your entire cloud infrastructure. This holistic approach to cloud security is what will ultimately keep your operations running smoothly, even in the face of sophisticated attacks. 

Synthesis 

In this article, we have examined three attack scenarios that threaten the security of the control plane in cloud environments: IT support compromise, Control Plane Admin’s laptop compromise, and CI/CD pipeline compromise.  

Each of these scenarios highlights the importance of a multi-layered security approach that includes both technical and organizational measures. We propose a four-step strategy designed to design your Control Plane and secure it against potential attacks: 

• Step 1: define what is systemic for your infrastructure: identify the critical components and accounts within your control plane that, if compromised, could lead to a global disruption.
• Step 2: assess your current risk with a security audit: conduct regular security audits to evaluate the current state of your control plane security. This will help you identify vulnerabilities and prioritize remediation efforts.
• Step 3: define a roadmap to isolate and secure the assets most at risk: based on your audit findings, develop a clear roadmap for securing the most critical assets. This should include timelines, resource allocation, and specific actions to mitigate identified risks. 
• Step 4: prepare for cloud eraser scenarios: consider worst-case scenarios where entire sections of your cloud infrastructure might be compromised or disabled. Develop contingency plans and ensure that backups and disaster recovery processes are in place. 

By following these recommendations, you can build a robust defense against potential threats to your control plane, ensuring that your cloud environment remains secure and resilient. 

Thank you to Louis CLAVERO for contributing to this article.

Cet article Enterprise Access Model (2/2): What are the solutions to secure the Control Plane  est apparu en premier sur RiskInsight.

However, setting up a relevant and effective CI/CD pipeline for each project context can be complex. Technologies vary, security requirements can differ, and target environments are not always identical. Given the ambitions and challenges posed by creating a unified CI/CD pipeline, it may not always be prudent to leverage IaaS or on-premise services, which also require infrastructure team investments. Cloud (PaaS) solutions offer a good middle ground between customizing the CI/CD pipeline and ease of implementation. Cloud solutions also allow for on-demand resource provisioning to better adapt to business needs.

There are numerous cloud-based CI/CD solutions that can potentially meet both security and efficiency requirements for the development pipeline. In this article, we aim to present our perspective on Amazon Web Services (AWS) solutions, which remain one of the market leaders.

What can AWS CI/CD services offer in terms of features and added value?

If you are not familiar with AWS CodeCommit, CodePipeline, CodeBuild, or CodeDeploy, we offer an introduction to better understand the workings of the AWS DevSecOps environment. To provide an overview of the tools offered by AWS, we describe the functionality of these different services in the following paragraphs.

Let’s start from the beginning: From DevOps to DevSecOps

DevOps is a key element in the software development lifecycle of companies. DevOps relies on CI/CD tooling and is  pipeline on which the evolution of source code into a production-ready application depends. CI/CD accelerates the phases of build, test, and deployment to increase the delivery frequency of applications. This acceleration is made possible by automating many tasks within a CI/CD pipeline, which is a series of actions leading to production deployment.

DevSecOps adds security aspects to DevOps and relies on certain internal tools within the CI/CD pipeline. These tools integrate at every level of the CI/CD pipeline to scan the source code (SAST – Static Application Security Testing), dependencies (SCA – Software Composition Analysis), and more. The goal, as discussed in our previous article, is to integrate security as early as possible. The CI/CD pipeline is a significant component in ensuring the security of developments. One could even say that the CI/CD pipeline plays as important a role in secure development as Identity and Access Management (IAM) does in identity and access management.

CI/CD in AWS

AWS offers a multitude of services that not only provide classic infrastructure services but also allow the establishment of continuous development pipelines (from source code to deployment), while ensuring proper security testing.

The orchestrator CodePipeline organises and links the different stages of the CI/CD pipeline. This tool coordinates the progression within the CI/CD pipeline based on the results of other tools and services. If one of the tools returns a failure code, the pipeline can be blocked if necessary. The reasons for a pipeline failure can vary, such as insufficient code security score or tool deployment failure.

Code Management: SCM and AWS CodeCommit

Code version control systems (or SCM: Source Code Manager) are essential tools for collaborative code editing during  development and serve as the starting point for continuous integration pipelines. Currently, only three SCMs offer native integration: GitHub, BitBucket, and AWS CodeCommit. For any other integration with a non-natively supported SCM, you can create a serverless Lambda function-based routine and a webhook (HTTP notification) to download source code to AWS S3 with each developer commit.

AWS CodeCommit is the SCM service offered by AWS. It’s a code hosting service that supports version control and collaboration, similar to GitHub or GitLab, with Git commands. The advantage of AWS CodeCommit is its full integration with the AWS environment, making it easier to interconnect with other AWS services. Using AWS CodeCommit also allows for the use of AWS Identity and Access Management (IAM), avoiding the duplication of identity repositories and role management within a third-party SCM. All of this makes AWS CodeCommit a suitable solution when used within an entirely AWS environment due to its close integration with other AWS services. However, AWS CodeCommit offers relatively limited features compared to GitHub such as user experience and interface, and has a smaller community than GitHub or GitLab. If the CI/CD pipeline includes multiple solutions external to AWS, other solutions such as GitHub or GitLab will likely provide more flexibility.

Build Phase: AWS CodeBuild

Once development is complete, AWS CodeBuild takes over. This tool can be used for both compiling/building an application and running tests via CI runners. The service executes the instructions provided in an input file called buildspec.yml. It is a versatile tool, similar to classic CI tools like GitLab CI or GitHub Actions.

AWS CodeBuild also allows for running security tests (SAST, SCA, etc.) by installing and using applications on its runners. Take SonarQube, for example, a code quality tool with a SAST module for scanning source code to identify vulnerabilities. The execution works as follows:

1. When the source code is modified, a webhook notification (HTTP POST request from the SCM) is sent to AWS (in practice, this event is managed by AWS EventBridge or AWS CodePipeline), triggering the test.
2. The source code is duplicated on the CI runner, which scans it and produces a report.
3. This report is then sent to a SonarQube server (on-premise or on an EC2).
4. After analysis, SonarQube produces a final report indicating the code’s security level.
5. These results are sent to CodeBuild, which interprets, based on the conditions in the buildspec.yml file, whether the test was successful or not.

Again, the key advantage of CodeBuild is its integration with the environment, allowing close collaboration with other AWS services. For example, it’s easier to assign specific roles to CodeBuild projects, use AWS Secrets Manager (for secret management), or enable deployment with AWS CodeDeploy.

Deployment: AWS CodeDeploy

The deployment of an application marks the end of its development cycle. Within AWS, deployment is achieved through AWS CodeDeploy. Its role is to retrieve the artifacts and necessary configuration files from dedicated S3 buckets and deploy them on the chosen server (EC2, etc.). AWS CodeDeploy differs from AWS Elastic Beanstalk, which deploys an application solely based on its code (usually not supporting compiled languages like C/C++).

CodeDeploy operates by deploying code to any type of server, whether hosted by AWS or not. Its operation is simple: an agent (CodeDeploy agent) is installed on the target server. This agent is responsible for downloading the artifacts, installing them, and launching the application.

It is necessary to define in advance the instances involved in the deployment and assign them an arbitrary AWS tag for identification. All these instances then constitute a “deployment group.” When deployment is initiated, CodeDeploy selects the relevant instances and publishes its instructions. However, communication is initiated by the target instance; the CodeDeploy agent contacts the CodeDeploy service by polling for new instructions (polling mode). This communication method avoids opening ports, enhancing the security posture of the instance.

AWS CodeDeploy is an effective tool for deploying code to any type of infrastructure. However, it requires the installation of an agent managed by AWS on the instance where the code is deployed, which may not always be desirable depending on the client’s context. Polling by EC2 instances may impact the performance of a critical application or be detected as malicious by Endpoint Detection and Response (EDR) or Network Detection & Response (NDR) systems.

Securing the AWS CI/CD Pipeline

Given the critical role of the CI/CD pipeline in application development, it is essential to secure this infrastructure, including tooling, integration, and pipeline configuration. Below, we summarise some areas to consider when implementing an AWS CI/CD pipeline, which can be managed through the creation of AWS policies to alert or enforce their application.

Flow Management

By default, flows to AWS managed services (CodeBuild, CodeDeploy, etc.) transit over the internet before returning to the client instance of the resource. To avoid sending all flows to AWS services over the internet, we recommend setting up VPC endpoints. These network access points allow instances within a VPC to contact AWS services as if they were deployed within the VPC.

Secret Management

Secrets required to access services or other APIs should not be stored in plaintext in SCMs or pipeline configuration files. To avoid any leakage of confidential information during legitimate or unauthorised access to these directories, we recommend implementing an AWS Secret Manager to store secrets (e.g., SonarQube API keys) and distribute them to services only when necessary. Retrieving a secret is done through an API call to this vault, with privilege verification.

Supervision/Monitoring

Like any infrastructure, the CI/CD pipeline requires monitoring. Native AWS solutions for service monitoring include AWS CloudWatch for log collection, AWS EventBridge for creating alerts, and AWS SNS/SQS for sending notifications to predefined groups (email, SMS, push notifications, etc.). Monitoring the CI/CD pipeline allows for alerting against potentially dangerous production releases, for example, if a project attempts to bypass implemented security policies.

Identity and Access Management

Privilege management within AWS is based on Role-Based Access Control (RBAC) whereby each user action requires specific permissions. For example, if a user wants access to an S3 bucket, they must first obtain read permission associated with the corresponding S3 resource. It is essential to adhere to the principle of least privilege, which involves assigning clients (users and services) only the rights they need. AWS permissions allow for complete configuration of client access to each service/resource. However, the granularity of rights can be cumbersome to configure in a large-scale CI/CD infrastructure. AWS offers predefined roles that allow for quick application of sets of permissions. Still, these predefined roles often do not adhere to the principle of least privilege. Therefore, it is important to create roles that apply the principle of least privilege without delving into micromanagement of rights.

Our Beliefs on AWS CI/CD

The CI/CD solutions available in AWS cloud are interesting and natively integrated with other AWS services. Native integration is particularly useful in the case of a pipeline hosted entirely by AWS. When most of a company’s infrastructure is already migrated to AWS, you can take advantage of interconnections between services and powerful access management and monitoring solutions with minimal additional configuration. However, for a simple and isolated use case, AWS CodeCommit or AWS CodeBuild might not be the preferred choice. Solutions such as GitHub and GitLab offer more comprehensive solutions, better integration with other vendors, and a more user-friendly interface. Similarly, regarding security, AWS does not offer native CI/CD security services for code validation (SAST, DAST, etc.). AWS does not provide native integration, but third-party services can still be integrated relatively easily.

*Example of BitBucket Integration in AWS CodeBuild – Source

Cet article CI/CD in AWS: The Solution to All Your Problems? What You Need to Know. est apparu en premier sur RiskInsight.

In previous articles, we talked a lot about how security should be organised to accompany agile projects: the change in the security paradigm to ensure Security by Design, how to organise the ISS teams in the face of these changes, the possible methodologies for continuing to analyse risks or get security approvals (and a general reminder of what security looks like in agile).

These articles were mainly about the organisational and methodological paradigm shifts that ISS teams were undergoing, to be able to best support projects, which deliver code much faster.

The links between Agility and DevOps

By shifting the focus towards the development teams, it is now a question of dealing in greater depth with software solutions and processes enabling security to be integrated directly into the development pipelines and into the daily lives of developers, where Agile and DevOps methodologies, although they aim to provide the best value to customers, will be expressed differently.

As the DevOps movement was born later than Agile methods, development teams were organised earlier than operations in an iterative and rapid mode for application and service delivery. DevOps principles bridge this gap by bringing Operations and Development teams closer together, and by offering solutions to accelerate delivery through the strong automation of the software development lifecycle, via CI/CD pipelines. In the end, the two approaches feed off and complement each other, to deliver faster and with better quality, thanks to the automation of a large number of tasks, thus avoiding human errors.

What about security?

Back to our topic of interest, it is now a question of automating security as much as possible. Just like the Agile and DevOps methods, Security in Agile and DevSecOps are also closely related. The idea is to bring security closer and closer to the development teams, but also make it as fast as possible. A key profile of the security principles in Agile is perfectly suited to DevSecOps: the Security Champion. As described in the article “How to structure SSI teams to ensure security in Agile at scale“, this is the security ambassador within the development teams. They are an integral part of the product team and are present in every sprint. Their role is to ensure that security is considered in each sprint in the development of User Stories (by integrating Evil or Security User Stories already written, or by helping to write them). The Security Champion can come from the world of development and become more skilled in security issues, with the help of the Security Guild.

To take it a step further, the Security Champion can also help their team understand automated security solutions, with the help of a specialist from the ISS team, who will help them to develop their skills in application security.

Having said that, is it because Agile Security and DevSecOps are linked that one should automatically embark on a transformation programme towards DevSecOps?

Some preparatory questions for embarking on DevSecOps.

In line with any major transformation project, it is worth asking why you are doing it, making sure you have a plan and the right sponsorship. DevSecOps is no exception to the rule, even if the questions to ask are specific.

Defining the scope and objectives

Firstly, before you start, you need to identify your motivating factors. Is it to deliver faster? Better? More securely? Will the problems encountered by the Dev, Sec and Ops teams be resolved by bringing the skills together? This is to prioritise efforts and ensure that the project can be ‘sold’ to sponsors. Next, the scope must be identified, trying to delimit it between transitional scope (short and medium term) and target scope (long term). Work can start on an application portfolio, a factory for testing, followed by creation of a roadmap for deploying the model to the full scope.

The current maturity of the organisation in terms of tooling and automation in the product development cycle should be assessed. A good knowledge of the tools used in the pipelines is a prerequisite. If there are still too many grey areas, an inventory of existing tools and an inventory of the practices and processes in place should be put together first.

Presence of the essential building blocks of the CI/CD pipeline

Before security can be integrated into development pipelines in an automated manner, it is first necessary to ensure that we have a good vision of what a state-of-the-art pipeline might look like. It is possible to embark on a DevSecOps programme without operational pipelines already installed but having a clear idea of the target is key. Here are some examples of solutions:

Figure 1 – the essential building blocks of a DevOps pipeline

The company must also be able to quantify the developments carried out internally or externally, with development agencies. Indeed, a complete pipeline will be useful for companies developing mainly in-house: it is an indispensable tool for developing quickly, with the right security tools integrated into the pipeline. In the case of external developments, the principle is different, and security is less “easy” to control: agencies will not necessarily give access to their pipelines or their source code. They may only deliver executables or images, via remote repositories for example. Integrating security is therefore done by more traditional means: via Security Assurance Plans (SAPs) for example, or by contractually obliging agencies to train their developers in application security, via training software solutions (for example CodeWarrior, which delivers ‘belts’ according to the level of training achieved).

Secondly, one of the most important ideas is that the pipeline is built in stages. In line with the “test and learn” approach dear to Agile methods, a “pilot” version of the pipeline can be deployed for a volunteer product team to test it over a few weeks/months. The deployment is then carried out progressively, according to a pre-established roadmap. In most cases, companies first set up a DevOps pipeline, with a few codes analysis tools (most often quality-oriented), then, once the pipeline is considered functional, the security tools are added.

However, it could be worthwhile to consider security tools as an integral part of the CICD pipeline. They could then be integrated into it progressively, according to a prioritised roadmap, as proposed below.

Here are some examples of tools that make up the security stack:

Figure 2 – Examples of security solutions to be integrated into the CICD pipeline (DevSecOps)

According to our feedback from the field, some tools are “easier” to implement and are therefore implemented as a priority.

Static Application Security Testing (SAST) tools

As mentioned earlier, these tools are nearly always already present in the initial pipeline, in their code quality testing format. Here it is a matter of configuring them to go one step further and perform security analysis of static code. This type of tool can be integrated at several points in the pipeline, in a “shift-left” logic, i.e., integrating security as early as possible in the pipeline. It can be positioned directly on the developers’ IDEs (integrated development environment), to provide them with “real-time” feedback on errors that could introduce vulnerabilities. It can also be used at the time of code compilation.

A disadvantage of this type of tool is the high number of false positives. The configuration is scalable and improves over time. However, the governance and processes around the tool need to be thought out in advance: a vulnerability triage team can be a solution, as well as training security champions to spot false positives, with the help of an application security expert (an Application Security Engineer for example).

SCA (Software Composition Analysis) tools

These tools should logically be installed as a priority, as developers make great use of open-source libraries to develop their products. The SCA will check the components of the library, such as licences, dependencies, vulnerabilities, and potential exploits. Many attacks originate from the uncontrolled use of open-source libraries that may contain critical vulnerabilities (such as the Log4Shell exploit).

This tool can be used like SAST, on IDEs or before compiling the code.

DAST tools

DAST tools scan running application builds for security vulnerabilities. They allow the simulation of a malicious attacker’s behaviour through automated pen tests and detect common security vulnerabilities such as OWASP 10. These tools may be less easy to use in authenticated mode (authentication is difficult in automatic mode, it must be done manually before running a test). The tests also take longer than a static scan, and dedicated time must be set aside so as not to disrupt the work of developers or production.

They can be used at the time of testing, but also in production.

It is necessary to think very early on about the governance and processes to be put in place around these tools, in particular by ensuring that developers cannot ignore detected vulnerabilities (by passing them as “false positives”, for example) and to ensure that vulnerabilities are centralised in a single tool (vulnerability management tool, for example), for greater efficiency.

Checking the presence of enabling technical prerequisites

The interest in working in DevSecOps may be limited on non-configurable and non-instantiable software package type applications.

On the infrastructure side, Infrastructure as Code (management and provisioning of infrastructure via code rather than manual processes) allows the use of containers or provisioned VMs that are key to use CICD pipelines more efficiently.

Not forgetting the whole governance and change management layer around the project

Make sure you build, or already have, an operating model that meets your needs (security champions, enabler teams, tooling, processes). Working in “agile at scale” mode is not mandatory for the first iterations (depending on the scope chosen).

Using a “test and learn” method to experiment is a good way to involve the teams very early on, and to get complete and relevant feedback from the field, before starting to deploy at scale. Cybersecurity experiments have been carried out with clients to find out what types of practices or tools to implement.

Some examples:

– Purple teaming to allow developers to see the results of another team’s testing tools and attempt to exploit them (allowing developers to see the reality of an attack and the potential ease of carrying it out),

– Implementing solutions such as Cloudbees, to automate the CICD pipeline processes,

– Training Security Champions to interpret the results of security tools.

These experiments also act as change management, as most stakeholders can be involved early in the transformation programme.

In conclusion

CICD pipelines are a real opportunity for security to become automated. By integrating the right tools into the pipeline, developers are supported in their practice, kept on real security guardrails, facilitating the development of a secure product.

In addition to securing the products, it is also a question of securing the pipeline itself, in the same way as any component with broad access to the information system: it is a question of controlling access to the various tools that make up the pipeline, ensuring that secrets are properly managed, that the underlying servers are hardened, etc.

In a future article, we will detail our views on the pillars of DevSecOps, or how to achieve a sustainable and effective transformation (based on shift-left, guardrails and empowerment of the teams on security!).

Any comments or corrections? Do not hesitate to contact us!

Cet article Security in Agility and DevSecOps: linked fates? est apparu en premier sur RiskInsight.