Security is an aspect that every enterprise needs to consider as they use and migrate to cloud-based technologies. On top of the list of resources that enterprises need to secure are networks, endpoints, and applications. However, another critical asset that enterprises should give careful security consideration to is their back-end infrastructure which, if compromised, could lead to supply chain attacks.
Normally, enterprises use endpoint- and network-based security solutions to protect their back-end servers and internal systems that store and process a considerable volume of valuable data. To optimize their operational costs, some enterprises move their back-end infrastructure to the cloud, or run their own on-premises private cloud using cloud-based solutions.
However, the previously mentioned approach needs to be executed correctly as not doing so could expose enterprises to attacks, such as the many past incidents of supply chain attacks that led to operational disruption, financial loss, and reputational damage. In the paper "Supply Chain Attacks in the Age of Cloud Computing: Risks, Mitigations, and the Importance of Securing Back Ends," we provide a rundown of multiple security risks we've analyzed and some mitigation techniques concerning DevOps, particularly those associated with Jenkins, Docker, Kubernetes, and cloud-based integrated development environments (IDE) such as AWS Cloud9 and Visual Studio Codespaces.
Default configuration in back-end systems poses significant security risks even when authentication is applied. Such risks have been uncovered in Jenkins, a popular open-source automation server for software development teams.
By default, the Jenkins primary can execute build jobs, allowing less-privileged users to completely overtake the Jenkins instance and leak secrets, job configuration, and source code. There is no Authentication or Access Control Lists (ACLs) model applied at all. If Jenkins’ matrix-based security is applied, users might feel that they are working with a secure configuration, but this is not the case because of the default capability to execute jobs on primary. To disable jobs execution on primary, the Authorize Project plug-in could be used, together with setting Shell executable to /bin/false on the Configure System page.
Another consideration that development teams need to take into account is the use of community plug-ins. Looking at Jenkins security advisories, most vulnerabilities in the Jenkins platform are related to plug-ins, most of which are improper secrets storage and sandbox-based escapes.
Docker is the most popular container engine used by development teams for application development, testing, packaging, and deployment. Since Docker became popular, many container images on Docker Hub have been found as malicious or have been abused to launch various attacks.
In 2020 alone, numerous threat actors have been spotted using malicious container images to mine cryptocurrency. The occurrence of these incidents highlights the need to use only official Docker images to mitigate potential security risks and prevent threats.
Exposed Docker APIs could also enable attackers to utilize the user’s server to deploy cryptocurrency miners. We also observed payloads deploying the AESDDoS botnet malware and recently, the Kinsing malware family. Privileged Docker containers and exposed daemon ports could also become attack surfaces that threat actors could leverage to conduct malicious activities.
Kubernetes is an orchestration tool that is relied on by development teams for scalable container deployment and management. Kubernetes services are offered by many cloud providers such as Microsoft’s Azure Kubernetes Service (AKS), Amazon’s Elastic Kubernetes Service (EKS), and Google’s Google Kubernetes Engine (GKE). Such managed services help reduce the risk of major misconfiguration issues. However, since this is not an option in some environments, misconfiguration-related risks could still exist when running Kubernetes clusters on premises.
The API plays a major role in Kubernetes security. If an application deployed inside a cluster can interfere with the API server, it should be considered as a security risk. Thus, the API should only be made available to devices that need it, a measure that can be done by implementing role-based access control (RBAC) authorization and ensuring the principle of least privilege.
In a misconfigured scenario, a single vulnerable application can serve as an entry point to the whole cluster. Users should ensure that only kube-api-server has access to the etcd (a distributed key-value store for storing critical data), as not doing so could lead to unintended data leakage or unauthorized modification. Meanwhile, a pod (a basic deployment unit inside a Kubernetes cluster) should be run with less privileges to avoid node or whole cluster compromise.
AWS Cloud9 and Microsoft’s Visual Studio Codespaces
Cloud IDEs combine all of the features and tools needed by a software developer. AWS Cloud9 and Microsoft’s Visual Studio Codespaces are two cloud IDEs commonly used by development teams. Visual Studio Codespaces is a whole application located in a linked environment, while in the case of AWS Cloud9, only back-end services are available on a linked machine, with front-end services located inside the AWS cloud.
The internal back-end implementation varies with the cloud IDE provider, but they all provide a terminal interface to the user’s environment. In most cases, users have full control of the environment along with the responsibility of ensuring secure configuration.
Since a user has full control of the linked device, they are responsible for preventing misconfiguration issues. These issues might occur when exposing ports for extended application usage by following an online tutorial since, for instance, AWS Cloud9 lacks support for plug-ins.
In contrast, Visual Studio Codespaces has a number of extensions available. However, this could also become a potential attack surface. For instance, a backdoored extension could lead to a system compromise due to the lack of permission checks for extensions during installation or use. To mitigate such risks, development teams should install only trustworthy plug-ins or extensions and update their environments to the most recent version.
Organizations run the risk of encountering more misconfiguration issues as the software that they use in their back ends becomes more complex. In line with this, development teams should keep in mind that there is no secure environment and expect that there could always be malicious intentions from internal and external actors. To further strengthen their back-end security, it is recommended for organizations to follow these best practices:
- Implement the principle of least privilege. Limit account privileges in cloud services, especially when linked to public cloud providers. In addition, restrict permissions and access to tools to prevent attackers from gaining a foothold in the computing environment.
- Do not use the admin user for daily tasks. The admin should only be used by continuous integration and continuous deployment (CI/CD) tools.
- Check for outdated or vulnerable libraries in the code. Tools like the OWASP dependency-check and solutions offered by Snyk provide free third-party verification for open source projects.
- Comply with industry standards. For instance, Kubernetes users can check the CIS Kubernetes Benchmark from the Center for Internet Security (CIS) to monitor critical files and directories, and the recommended ownership and permission levels. Container users could do the same by checking the Application Container Security Guide from the National Institute of Standards and Technology (NIST).
- Improve security and compliance posture. Employ real-time security that detects misconfiguration in cloud services to ensure protection in the pipeline. Solutions that have an auto-remediation function can also help in rectifying failures.
Cloud Security Solutions
Trend Micro’s Hybrid Cloud Security solution provides powerful, streamlined, and automated security within your organization’s DevOps pipeline and delivers multiple XGenTM threat defense techniques for protecting runtime physical, virtual, and cloud workloads. The Trend Micro Cloud OneTM security services platform provides organizations a single-pane-of-glass look at their hybrid cloud environments and real-time security with the following automated and flexible services:
- Workload Security can automatically protect legacy systems with virtual patching and cloud workloads from evolving threats through machine learning technology
- Application Security is an embedded security framework that proactively detects threats and protects applications and APIs on their containers, serverless, as well as other cloud computing platforms.
- Container Security detects threats, vulnerabilities, and exposed sensitive data such as API keys and passwords, within container images.
- Cloud Conformity performs hundreds of automated checks against industry compliance standards and cloud security best practice rules, improving the cloud infrastructures’ security and compliance posture.
- File Storage Security protects cloud file/object storage services that are on cloud-native application architectures via malware scanning and integrating into custom workflows.
- Network Security defends virtual private clouds by blocking attacks, threats, and detecting infiltrations.
Read our complete report, “Supply Chain Attacks in the Age of Cloud Computing: Risks, Mitigations, and the Importance of Securing Back Ends,” to learn more about such risks and how development teams can mitigate them.
Like it? Add this infographic to your site:
1. Click on the box below. 2. Press Ctrl+A to select all. 3. Press Ctrl+C to copy. 4. Paste the code into your page (Ctrl+V).
Image will appear the same size as you see above.
- Exposed Container Registries: A Potential Vector for Supply-Chain Attacks
- LockBit, BlackCat, and Clop Prevail as Top RAAS Groups: Ransomware in 1H 2023
- Diving Deep Into Quantum Computing: Modern Cryptography
- Uncovering Silent Threats in Azure Machine Learning Service: Part 2
- The Linux Threat Landscape Report