Linux Threat Report 2021 1H: Linux Threats in the Cloud and Security Recommendations
Many regard Linux as a unique operating system because of its stability, flexibility, and open-source nature. Its stellar reputation is backed by its many notable achievements in recent years. For example, 100% of the world's top 500 supercomputers run on Linux, and 50.5% of the top 1,000 websites in the world use it, according to a survey by W3Techs. Our previous article shared how Linux dominates the cloud, running on 90% of public cloud workloads in 2017. Linux is also uniquely supported for top price/performance cloud workloads using Advanced RISC Machines (ARM) processors, such as the AWS Graviton. And aside from running on 96.3% of the top 1 million web servers globally, Linux also powers smartwatches, high-speed trains, and even the world's major space programs.
Linux is powerful, universal, and dependable, but it is not devoid of flaws; like other operating systems, it is still susceptible to attacks. This article discusses the state of Linux security in the first half of 2021 and provides an in-depth look at the Linux threat landscape. We discuss several pressing security issues that affect Linux, which include the types of malware that exist in the Linux world, the vulnerabilities that affect the Linux operating system, and the various software stacks that run on it. This article will also cover web app security risks and how attackers abuse them to compromise Linux systems running in the cloud.
The data presented in this article comes from the Trend MicroTMSmart Protection Network™ (SPN), or the data lake for all detections across all Trend Micro's products. In addition, we also collected data from honeypots, sensors, anonymized telemetry, and other backend services. This data stands for the real-world prevalence of malware and vulnerability exploitation across enterprises — from small organizations to large corporations across various verticals.
The ubiquity of Linux
Before we delve into the specific threats that affect Linux systems, we would like to first share the prevalence of the various flavors or distributions of Linux and Unix from across our enterprise customer base. After all, Linux is undeniably ubiquitous, especially in the cloud, where it powers most infrastructures. Linux users comprise the majority of the Trend Micro Cloud One™ enterprise customer base at 61%, while Windows users are at 39%.
Figure 1. The percentage of Linux and Windows workloads protected by Trend Micro Cloud One
Figure 2. The percentage of various Linux distributions across workloads protected by Trend Micro Cloud One
Amongst the Linux/Unix-based deployments, Red Hat takes up a big chunk of enterprise users, followed by AWS Linux and Ubuntu. Enterprises rely on well-maintained sources of Linux deployments for their workloads, and this chart reflects the support provided by vendors. For example, Red Hat Enterprise Linux (RHEL) and Amazon Linux AMI are usually the first to offer patches to their supported versions. While this data distribution should not surprise most readers, it's worth noting that about 2.6% of these are IBM AIX and Oracle Solaris. AIX and Oracle Solaris are known for their stability and robustness; enterprises run critical workloads on these platforms.
Exposed Linux systems
Because Linux has a large footprint, there's bound to be a percentage of its administrators who would unwittingly expose Linux systems and, ultimately, critical data. Data from Censys.io, a search engine for internet devices, shows almost 14 million results when searching for exposed devices connected to the internet and running any sort of Linux operating system on July 6, 2021:
Figure 3. The total number of exposed Linux servers detected by Censys.io as of July 6, 2021 (Query: operating system.product=Linux)
A look at port 22 in Shodan, a port commonly used for Secure Shell Protocol (SSH) for Linux-based machines, revealed even more prominent results: almost 19 million devices connected to the internet have this port exposed:
Figure 4. The total number of servers with port 22 exposed as detected by Shodan as of July 27, 2021 (Query: port 22)
It is imperative for organizations not to leave such ports exposed to avoid attackers from gaining a foothold into Linux systems. In the past, we have observed attackers abusing these ports to launch malicious activities; last year, we published an article that described how attackers used botnets to perform brute-force attacks after scanning for open SSH and Telnet ports.
The Linux threat landscape: What are the top Linux threats?
With the goal of spreading awareness about Linux-based malware threats, we utilized Trend Micro SPN data to show how rampant malware families are in Linux systems. Because we were looking at millions of detections, we decided to examine the data through different lenses. In an article we published earlier this year, we categorized the data based on various malware types: ransomware, cryptocurrency miners, rootkits, malicious scripts, and web shells.
This time around, we present SPN data showcasing the prevalence of Linux as an operating system and the pervasiveness of the platform's various threats and vulnerabilities. Almost 40% of the detections came from the US, followed by Thailand and Singapore with 19% and 14%, respectively. It's also important to note that detections arose from systems running end-of-life versions of Linux distributions. The majority (almost 44%) of the detections were from CentOS versions 7.4 to 7.9, followed by CloudLinux Server, which had more than 40% of the detections, and Ubuntu with almost 7%.
Linux malware: Threats by the numbers
From over 13 million events that we identified and flagged from our sensors, we identified the top 10 malware families which we then consolidated by their threat types. Table 1 lists the top threat types affecting Linux servers from January 1, 2021 to June 30, 2021, based on data from Trend MicroTM Deep SecurityTM and Trend Micro Cloud OneTM - Workload Security. Note that some Windows-based malware families made the list, which means that Linux servers act as a storage or command-and-control (C&C) server for Windows malware.
Figure 5. We categorized the Top 10 malware families we detected according to their threat types. These are the top threat types found in Linux systems in the first half of 2021.
An interesting observation here is the high prevalence of coinminers, of which Coinminer.Linux.MALXMR.SMDSL64 and Coinminer.Linux.MALXMR.PUWELQ are the most prevalent families; and web shells, of which the most detected families are Backdoor.PHP.WEBSHELL.SBJKRW, Backdoor.PHP.WEBSHELL.SMMR and Backdoor.PHP.WEBSHELL.SMIC. Given that the cloud holds a seemingly endless amount of computing power, hackers have a clear motive in stealing computing resources to run their cryptocurrency mining activities. It’s also important to note that cryptocurrency miners have been plaguing container environments in recent years. We also saw ransomware as a prevalent Linux threat, and DoppelPaymer, a modern ransomware family that utilized double extortion tactics, is the most prevalent ransomware family based on our data. In our monitoring of the ransomware landscape, we have also recently seen other ransomware variants that were targeting Linux systems such as RansomExx, DarkRadiation, and even DarkSide.
Our SPN data shows the top four Linux distributions where we found the above mentioned top malware families:
Figure 6. The top four Linux distributions where the top threat types in Linux systems were found in the first half of 2021
Vulnerabilities in Linux systems
Our previous article discussed various vulnerabilities affecting the Linux platform and the software stack and applications that run on it. To further define the state of Linux security for the first half of 2021, we dissected IPS (Intrusion Prevention System) hits from Trend Micro Cloud One - Workload Security and sifted through over 50 million events, ignored false positives, eliminated test data, and layered data with available threat intel to draw some conclusions. It should be noted that there can be a degree of error here due to the nature of the data and internet activity.
These 50 million+ events that we dissected represent:
- More than 100,000 unique Linux hosts reported the events.The top 20 Linux and Unix flavors that reported events into this dataset by volume.
Figure 7. Volume of IPS events sorted by operating system in 1H 2021
Here, we look at the triggers for vulnerabilities known to be actively exploited or have a known proof of concept. Based on Trend Micro Cloud One data, the following list features the top 15 Common Vulnerabilities and Exposures (CVEs) that are being actively exploited in the wild or have existing proofs of concept. It should be noted that Trend Micro Cloud One provides protection against the top 15 vulnerabilities listed below via its virtual patching, vulnerability shielding, and exploit blocking features.
Top Vulnerabilities With Known Exploits or Proofs of Concept | CVE | Severity |
Apache Struts2 remote code execution (RCE) vulnerability | CVE-2017-5638 | Critical |
Apache Struts 2 REST plugin XStream RCE vulnerability | CVE-2017-9805 | High |
Drupal Core RCE vulnerability | CVE-2018-7600 | Critical |
Oracle WebLogic server RCE vulnerabilities | CVE-2020-14750 | Critical |
WordPress file manager plugin RCE vulnerability | CVE-2020-25213 | Critical |
vBulletin 'subwidgetConfig' unauthenticated RCE vulnerability | CVE-2020-17496 | Critical |
SaltStack salt authorization weakness vulnerability | CVE-2020-11651 | Critical |
Apache Struts OGNL expression RCE vulnerability | CVE-2017-12611 | Critical |
Eclipse Jetty chunk length parsing integer overflow vulnerability | CVE-2017-7657 | Critical |
Alibaba Nacos AuthFilter authentication bypass vulnerability | CVE-2021-29441 | Critical |
Atlassian Jira information disclosure vulnerability | CVE-2020-14179 | Medium |
Nginx crafted URI string handling access restriction bypass vulnerability | CVE-2013-4547 | N/A |
Apache Struts 2 RCE vulnerability | CVE-2019-0230 | Critical |
Apache Struts OGNL expression RCE vulnerability | CVE-2018-11776 | High |
Liferay portal untrusted deserialization vulnerability | CVE-2020-7961 | Critical |
Table 1. The top 15 vulnerabilities with known exploits or proofs of concept
Table 1 shows the top vulnerabilities by volume of triggers. In total, we see about 200 different vulnerabilities triggered across the board. A noteworthy point here is that even though there are an estimated 20,000 vulnerabilities reported in 2020 alone — many of which affect Linux or the Linux application stack — only 200 of those vulnerabilities have publicly known exploits and were observed. Striving to prioritize the patching of these vulnerabilities should be an approach baked into any organization's security practices. Trend Micro uses an approach that focuses on weaponized vulnerabilities to ensure that the most likely to be exploited get protected first.
The applications affected by these 200 vulnerabilities have a few clear targets, including WordPress or Apache Struts, but services such as Atlassian JIRA, dnsmasq, and Alibaba Nacos aren't the first ones a security expert would automatically assume to be in attackers’ crosshairs. Based on our data, the top triggers are spread across the following applications:
Figure 8. The applications with the most number of triggers from the abovementioned top vulnerabilities with known exploits or proofs of concept
OWASP top 10 and beyond
Most of the applications and workloads exposed to the internet run web applications. Web application attacks happen to be the most common attack vector in our telemetry. If launched successfully, web app attacks can allow hackers to execute arbitrary scripts, compromise secrets, or modify, extract, and even destroy data. In this section, we start by comparing the spread of web and non-web attacks on Linux systems. As shown in Figure 8, 76% of the attacks are web-based, while only 24% of the attacks are non-web in nature.
Figure 9. The percentage of web-based and non-web-based attacks in the first half of 2021
It's worth dissecting these web-based attacks under the Open Web Application Security Project (OWASP) lens. But since the OWASP Top 10 ranks the ten most critical web app threats and risks, what about other web-based attacks and their prevalence? Let's look at the OWASP Top 10 and beyond it.
Before we go further, note that the succeeding data stands for volume-based analysis of Linux environments. Therefore, this data does not undermine the importance of the OWASP Top 10. Instead, this data highlights activity more than importance. For example, brute force attacks are so rampant that they dwarf any other OWASP Top 10 security risk. Obviously, an attacker would need to keep trying in a brute force attack, hence the volume of events.
Figure 10. The percentage of OWASP Top 10 attacks and non-OWASP attacks in the first half of 2021
With Linux being the first choice for web servers and applications, the OWASP Top 10 has become more relevant to the operating system. Since 76.9% of the top 10 million web servers globally are Unix-based, the OWASP web app risks act as an important filter when looking at vulnerabilities affecting Linux/Unix systems.
Looking only at the OWASP 10 security risks, we see that injection flaws and cross-scripting (XSS) attacks are as high as ever. What sticks out in this chart is the high number of insecure deserialization vulnerabilities. This is partly due to the ubiquity of Java and deserialization vulnerabilities in it. Other than that, we have also observed Liferay Portal, Ruby on Rails, and Red Hat JBoss deserialization vulnerabilities. Attackers also try to use vulnerabilities where there is broken authentication to gain unauthorized access to systems. The number of command Injection hits also came as a surprise as they are higher than what we would have expected.
Figure 11. The top OWASP security risks by volume
Layering brute-force, directory traversal, and request smuggling attacks, the three most prevalent non-OWASP security risks based on our data, on the chart in Figure 11 shows the state of exploitation of these security risks based on the volume of activity:
Figure 12. Volume of activity comparison between top OWASP security risks and non-OWASP security risks
What are open-source security (OSS) and software supply chain attacks (SSCA)?
When talking about application security, we need to be aware that most applications rely on libraries and dependencies that are, for the most part, open-source software. These libraries are usually incorporated during the development lifecycle and rarely get updated or checked against known vulnerabilities.
Another pertinent aspect that must be secured is software supply chains. Attackers can compromise software components of third-party suppliers by inserting malicious code inconspicuously. This code will then connect to a C&C server and download and deploy backdoors and other malicious payloads within the system. This can lead to RCE and unhampered access to an enterprise's system and computing resources. Supply chain attacks can also come from misconfigurations, which we discussed in a report published earlier this year. According to a report by Snyk, Trend Micro’s open source security partner, misconfiguration is the second top incident type in cloud native environments. More than 56% of their survey respondents experienced a misconfiguration or known unpatched vulnerability incident involving their cloud native applications.
On May 12, 2021, US President Joe Biden signed an executive order (EO) to improve US cybersecurity and protect their federal government networks. Section 4 of the EO detailed the enhancement of the security for the software supply chain. The goal is to improve software security by establishing a baseline of secure coding standards for applications sold to the US government, such as requiring organizations to maintain greater visibility into their software and making security data available to the public.
Figure 13. Comparison between a traditional supply chain and a software supply chain
While the software supply chain is similar to the traditional supply chain regarding the journey it takes to reach its end goal, the software supply chain is often more complex, requiring more layers of checking and security.
In October 2020, we published a whitepaper, “Supply Chain Attacks in the Age of Cloud Computing: Risks, Mitigations, and the Importance of Securing Back Ends,” which discusses multiple security gaps and risks related to the world of DevOps, where cloud services play a major role in digital and business transformation.
In Gartner's 2019 report, “Technology Insight for Software Composition Analysis,” concerns about security vulnerabilities such as the use of untrusted third-party components and the lack of vendor accountability tops the most significant challenges with operations support systems (OSS).
The term software composition analysis (SCA) is relatively new to the world of cybersecurity. But similar approaches have been used since the early 2000s to indicate security verifications on open-source components. SCA, an evolution of early verification systems, identifies and lists all the parts and versions present in the code. It also includes the checking of each specific service and looking for outdated or vulnerable libraries that may impose security risks to the application. These tools can also check for legal issues regarding the use of open-source software with different licensing terms and conditions.
Container security
Containers are a big part of the Linux ecosystem — and it is also largely targeted by attackers. In an article that we penned in 2019, we delved deep into the various possible threats and risks to container environments at various stages in the development pipeline, including malware embedded in container images, hijacked image registries, and Docker and Kubernetes API abuse. The following table shows the vulnerabilities for the 15 most popular official Docker images on Docker Hub and the number and level of vulnerabilities for each that we found using our image scanning solution, Trend Micro Cloud OneTM – Container Security, on June 9, 2021.
Image | Total Vulnerabilities | Critical | High | Medium | Low | Others |
python | 482 | 32 | 129 | 246 | 38 | 37 |
node | 470 | 32 | 126 | 238 | 37 | 37 |
wordpress | 402 | 26 | 109 | 198 | 40 | 29 |
golang | 288 | 10 | 87 | 157 | 13 | 21 |
nginx | 118 | 18 | 41 | 44 | 7 | 8 |
nginx | 118 | 18 | 41 | 44 | 7 | 8 |
postgres | 86 | 8 | 32 | 35 | 6 | 5 |
influxdb | 85 | 8 | 33 | 34 | 6 | 4 |
httpd | 84 | 7 | 33 | 32 | 6 | 6 |
mysql | 76 | 9 | 28 | 31 | 5 | 3 |
debian | 66 | 7 | 26 | 25 | 5 | 3 |
memcached | 65 | 7 | 25 | 25 | 5 | 3 |
redis | 65 | 7 | 25 | 25 | 5 | 3 |
mongo | 47 | 3 | 18 | 23 | 3 | 0 |
centos | 68 | 7 | 36 | 23 | 2 | 0 |
rabbitmq | 30 | 1 | 7 | 20 | 2 | 0 |
Table 2. The 15 most popular Docker images and the number and level of vulnerabilities for each
How to secure Linux servers
In the foreseeable future, enterprises and organizations will continue to depend on Linux to power their digital infrastructure, including their mainframes, servers, web development platforms, and mobile applications. And malicious actors will look for every opportunity to compromise the platform for financial gain — whether by developing and launching malware, exploiting vulnerabilities, or taking advantage of misconfigurations. Keeping Linux, the bedrock of critical systems and services, protected against threats can be achieved using a multilayered security approach: maximizing built-in tools and trusted commercial or free third-party security control. This section will cover these security recommendations and best practices.
How to secure Linux using native Linux tools and configurations
Linux Tool or Configuration | Description |
iptables | This Linux rule-based firewall utility can be used to set up, maintain, and inspect the tables of IP packet filter rules in the Linux kernel. This means that iptables can effectively allow or block traffic by looking for a rule to which a connection request is matched. This tool usually comes installed by default on most Unix or Unix-based operating systems. |
seccomp | The secure computing (seccomp) mode is a popular Linux kernel security feature that restricts access to system calls (syscalls) by processes. This means that seccomp can filter syscalls and allow or limit which syscalls can be executed in the system. |
AppArmor | AppArmor is a mandatory access control (MAC) security system for Linux applications. It uses program profiles to restrict the capabilities of individual programs. |
SELinux | Security-Enhanced Linux (SELinux) Linux is an application of a hardened MAC designed to meet various security requirements. It applies security labels to objects and evaluates all security-relevant interactions via the security policy. When a subject (such as an application or a process) requests to access an object (such as a file), SELinux will check the permission assigned for subjects and objects via an access vector cache (AVC). |
grsecurity | This is an extensive set of security enhancements for the Linux kernel that uses role-based access control (RBAC), memory corruption-based exploit prevention, and a host of other system hardening features that defend against a wide range of security threats. These patches are used to check remote connections from untrusted locations, such as web servers and systems offering shell access to their users. |
PaX | PaX adds intrusion prevention mechanisms to the Linux kernel, which reduce the risks posed by exploitable memory corruption bugs. A few key features of PaX are enforcing non-executable pages, preventing kernel code reuse attacks, sanitizing freed memory, adding address space layout randomization (ASLR), and preventing potential misuse of userland pointers in the kernel. PaX also makes novel use of GCC plugins to constify applicable types, defend against some Spectre variants, and harden the kernel's memory allocator. |
Table 3. Native Linux tools or configurations
For more information about Linux kernel security features, Linux provides a helpful article that gives a high-level overview of Linux security extensions.
How to secure Linux using third-party tools and controls
The following are notable security controls your multilayered security solutions should have in order to keep Linux threats at bay:
Antimalware
Antimalware is the first line of defense and basic hygiene on any operating system. Antimalware would pick and prevent known scripts (remember that web shells are scripts) and malware from running in the system. In addition, advanced controls in antimalware can detect malicious activity through behavior monitoring or system activity. It’s important to note that not all anti-malware solutions have a focus on Linux-based malware, hence, it’s important to carefully consider the anti-malware for Linux.
Intrusion prevention/detection system (IPS/IDS)
Deep packet inspection products inspect network traffic to detect or prevent possible intrusion. These products can be an agent-based IPS running on the workload or a network appliance, with controls that can prevent vulnerabilities from being exploited. In addition to vulnerability protection, these systems also provide rules or filters that can be useful in detecting or preventing attackers' lateral movement (east-west traffic) and detecting command and control connections from previously infected workloads.
Some IPS systems can even allow their customers to write their own rules to contain outbreak situations.
Execution control
Often known as application control and leaning towards the zero-trust model, execution control is a broader all-encompassing term for a control that can limit which software and scripts can run on a computer. Simply blocking executables leaves a huge blind spot, but defining policies to allow or disallow types of script files (e.g., PHP, Bash, Perl, Python, etc.) and even specific scripts, provides more control and flexibility. This control is most effective if coupled with feedback by a known "good" feed source.
Configuration assessment
A particularly crucial step to ensure that Linux systems are configured properly is to run regular scans to check for any misconfigurations. This includes ensuring that the operating system and its dependencies, and all the applications running on it are properly configured. They are two vastly different things. Scanning for operating system configuration issues does not certify the system is in a "safe" state. The application stack can open up severe problems if not correctly configured.
Vulnerability assessment and patching
Vulnerability assessment tools provide a periodic snapshot or continuous monitoring of missing patches. They help prioritize the most critical patches based on the severity of the vulnerabilities discovered. If the change management process doesn't allow immediate patching, an IPS must be deployed to deploy the available virtual patches.
Activity monitoring
It can take months before a breach can be detected. Given the recent shifts in malware and the threat landscape, it takes more than traditional controls to protect users and enterprises against sophisticated cyberattacks. Continuous activity monitoring through a managed service or by a security operations center (SOC) team enables streamlined detection of any suspicious network activity.
Managed detection and response (MDR) or extended detection and response (XDR) services can help detect malicious activities, with threat intelligence from various sources, helping catch threats faster and improve investigations, analysis, and response times.
How to secure containers
When it comes to container security, there are three questions that enterprises and organizations need to ask themselves:
How secure are the container images?
This comes down to ensuring one's containers are up-to-date and free of any vulnerability that cybercriminals can exploit. Organizations should secure the base image and ensure that the applications running in their containers have been scanned and verified. Although some open-source tools are available for this purpose, not all can detect vulnerabilities beyond operating system packages. For this, organizations can use a solution that also covers application vulnerabilities.
Can the container images be trusted?
Are the containers running in the system built from the images in one's registries? How can you ensure that? Using image-signing tools such as The Update Framework or Notary users can sign their images and maintain a system of trust for the content of their containers. We recently published an article that expounds on this topic.
Are the container images running with proper privileges?
The principle of least privilege applies here. Enterprises should only run containers with users having the minimal operating system privileges that are necessary to carry out their tasks. We previously expounded on why it's a bad idea to run privileged containers in Docker, or containers with all the root capabilities of a host machine.
We created a comprehensive guide on how containers can be better protected by examining potential threats at each stage of the development pipeline.
Following these basic Docker best practices, provided by Snyk, will help enterprises keep their containers secure:
- Use lightweight base images such as Alpine Linux
- Apply the principle of least privilege; don't run containers as root or in privileged mode
- Sign and verify container images to protect them against supply chain attacks
- Actively scan and fix vulnerabilities in container dependencies
- Don't hardcode secrets or credentials on container images
How to secure code via application security and testing
Also referred to as code security, application security is the layer over which organizations and enterprises have the most control. The code of an organization's applications is the heart of its critical systems. Together with the applications' respective databases, these codes are usually exposed to the internet — hence, attackers will focus on compromising them if all other components are appropriately secured. So how can you ensure that your apps are securely coded when you have tens, hundreds, or maybe thousands of developers writing and deploying code every day to their production environment?
Organizations must ensure that all communications are being made using TLS encryption. This should be applied even among internal services like load balancers, application servers, and databases.
Organizations can significantly reduce the attack surface of their systems just by limiting and monitoring exposed services, ports, and API endpoints. Here, it is essential to also think about container base images and the systems on which its clusters are running.
There are various code security verifications to add to your pipeline to ensure that one's code is secured:
Static application security analysis (SAST)
This is also called “security code review” or “code auditing,” and is still one of the best and quickest ways to detect security issues in one's code. Regardless of the language being used, enterprises should have at least one static analysis tool embedded into the pipeline. This tool will check for unsafe coding practices every time developers commit new code into the application. In addition, the OWASP Foundation has a list of open-source and commercial tools designed to analyze source code or compiled code to detect security flaws.
Dynamic application security analysis (DAST)
Although dynamic analysis can only be done when there is a running application to test against, it is also a good idea to perform automated scans and checks to test for common application attacks such as SQL injection, XSS attacks, and cross-site request forgery (CSRF) attacks. These tools will also test your application, container, and cluster resilience when faced with a series of unexpected load and malformed requests. In addition, OWASP has a dynamic analysis tool that can also be automated and embedded into the pipeline called OWASP Zed Attack Proxy (ZAP).
Software composition analysis (SCA)
Between 70% and 90% of all cloud-native applications are made of libraries or third-party dependencies. These are chunks of code — which could have been written by someone outside one's organization — embedded and running inside an organization's production systems. These codes are generally not checked during the static analysis phase. However, tools like the OWASP dependency-check can be used to check for outdated or vulnerable libraries in one's code. Trend Micro Cloud One - Open Source Security by Snyk provides cloud-native application security via continuous monitoring and by identifying open-source code vulnerabilities and license risks in application components.
Runtime Application Self-Protection (RASP)
RASP is a strong application security tool that kicks in when an application starts, providing real-time or immediate protection against threats and attacks, such as zero-day exploits, XSS attacks, and email and messaging app attacks. RASP not only detects attacks, but it also analyzes the attacks’ behavior and the context of the behavior. This means that it can correctly pinpoint legitimate requests from attacks, minimizing false positives and gray alerts. Trend Micro Cloud OneTM – Application Security offers RASP, which allows developers to design and deploy secure applications and protect against sophisticated attacks quickly and efficiently.
Patching and ensuring that proper configurations are set are separate tracking items. The responsibility for these rests with the application owners and their application security teams. DAST and penetration testing are usually helpful in identifying vulnerabilities and configuration issues. Enterprises can deploy systems that can prevent such from happening or perform virtual patching, such as a web application firewall (WAF) or an IPS.
Conclusion and Trend Micro solutions
Linux allows organizations to make the most of their cloud-based environments and power their digital transformation strategies. And with its popularity and wide-ranging user base, it's important to learn about the threats affecting Linux to properly defend systems — especially the pervasive ones. The data and real-world attack examples highlighted in this article are expected to provide the reader with a clearer picture of the threats looming around Linux systems. Given how deeply Linux is rooted in daily life, especially as an integral part of cloud infrastructure and the internet of things (IoT), the security of Linux and Linux workloads must be treated at par with that of Windows and other operating systems.
Users and organizations should always apply security best practices, which include utilizing the security by design approach, deploying multilayered virtual patching or vulnerability shielding, employing the principle of least privilege, and adhering to the shared responsibility model.
Enterprises can also benefit from multilayered security solutions such as the Trend MicroTM Cloud OneTM, a security services platform for cloud builders. It provides automated protection for cloud migration, cloud-native application development, and cloud operational excellence. It also helps identify and resolve security issues sooner and improves delivery time for DevOps teams. It includes the following:
- Cloud One - Workload Security: runtime protection for workloads
- Cloud One - Container Security: automated container image and registry scanning
- Cloud One - File Storage Security: security for cloud file and object storage services
- Cloud One - Network Security: cloud network layer IPS security
- Cloud One - Application Security: security for serverless functions, APIs, and applications
- Cloud One - Conformity: real-time security for cloud infrastructure — secure, optimize, comply
- Cloud One - Open Source Security: Visibility and monitoring of open source vulnerabilities and license risks
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.
Recent Posts
- Unleashing Chaos: Real World Threats Hidden in the DevOps Minefield
- From Vulnerable to Resilient: Cutting Ransomware Risk with Proactive Attack Surface Management
- AI Assistants in the Future: Security Concerns and Risk Management
- Silent Sabotage: Weaponizing AI Models in Exposed Containers
- AI vs AI: DeepFakes and eKYC