December 1, 2020 in Training by Ell Marquez5 minutes
This blog was originally written for and published by Intezer.com
Blogs about Linux cloud security are nothing new. However, most are filled with technical jargon that can make them difficult to understand. For example, phrases such as:
“Ensure your AMIs are configured for your EC2 instances as well as your S3 buckets.”
Fortunately, as this is not just another Linux security blog, we are going to keep it simple, informal, and easy to understand by dispelling some of the most common misconceptions around Linux security.
Misconception #1
There is a notion in our community that added Linux operating system security features, such as Security-Enhanced Linux (SELinux) along with cloud provider offerings such as cloud-based firewall rules and access management, offer security by default. Companies do not need to focus on the hardening of the cloud server itself.
The Truth
Misconceptions such as these can lead companies to suffer devastating losses. When securing Linux servers, whether physical or in the cloud, the basics still remain the same. Just because a server is running Linux does not mean you can be lenient on security practices on the server itself. A company's security posture frequently relies on cloud providers' security controls, and while they do provide help, if the company does not know what code is running on their servers the effectiveness of the providers' security controls are negated.
The Challenge
Software development has changed drastically over the past several years to meet the need for faster time to market conditions. To accommodate these requirements, developers are increasing the frequency of their code deployments. Capital One reports they are currently deploying up to 50 times per day for a single product, with Amazon, Google, and Netflix deploying thousands of times per day. With the frequency of these code changes, it is becoming increasingly difficult for security teams to adapt their monitoring and hardening practices.
New code deployments can alter a server's expected behavior. Suppose companies are focusing their monitoring on behavior-based detection. In that case, new code deployments can lead to false positives, which create an additional workload for teams. Security teams often report that it's challenging to address these situations as they do not have enough visibility into what code is running on their servers. Thus, they must spend a significant amount of time investigating them. If attackers can craft their code to fit with the expected behavior, no alerts are triggered, and a compromise could occur without any detection. However, companies are often worried about deploying new security solutions as they may degrade performance by using vital resources or slowing down the development process.
Misconception #2
Attackers focus on Windows as it's the world's most used operating system.
The Truth
The number of threats that Linux servers face are downplayed due to another common misconception about the popularity of Linux's usage around the world. The belief is that Windows is the primary operating system in use, and while this might be true for desktop computers, when it comes to Linux cloud or physical servers, the numbers say it all.
The Challenge
In the past decade, researchers have discovered many advanced persistent threat campaigns targeting Linux systems using adapted Windows malware, as well as unique Linux malware tools tailored for espionage operations. Once the code was modified to work in Linux environments, there was no barrier to shifting these attacks to new targets. One example is IPStorm; researchers first saw this malware in 2019 targeting Windows systems. IPStorm has now evolved to target other platforms such as Android, Linux, and Mac devices, leading to increased compromised systems of more than 13,500. Detecting if systems are compromised is not always difficult; however, many businesses are unaware they should examine their devices until they see this attack's impact. The increase in compromised systems has led some to call IPStorm one of the most dangerous malware in existence.
Perhaps one of the leading factors for attackers deciding to morph their attack strategies is the growth of cloud technology and the increasing number of cloud providers making the transition to Linux-based environments easier than ever.
Even governments have embraced Linux's usage in their environments. For example, in 2001, the White House transitioned to the Red Hat Linux-based distribution. The US Department of Defense migrated to Linux in 2007, and the US Navy's warships have been using Red Hat since 2013. The US is not alone in this transition. The Austrian capital of Vienna and the government of Venezuela have also adopted the use of Linux.
Misconception #3
Open-source software is inherently secure, due to the visibility of the code and contributions from the community.
The Truth
Attackers contribute to open-source projects as well. For example, we have seen NPM packages that contained code providing access to the environmental variables, allowing for the collection of information for the host device.
Not everyone has the skills to understand the code, so despite seeing the installed code, the compromise can go undetected. When an issue is reported, an experienced developer reviews the code, then writes a patch. Once this work is done, we wait for the new code to be approved. Don't forget during this time unknowing parties would still be using these packages.
Once a fix is available, many companies still do not upgrade the new code. The State of Software Security (SOS) analyzed 85,00 applications and found that over 75% shared similar code. 47% of these had flawed libraries used by multiple applications; 74% of these libraries could have been fixed with a simple upgrade.
The Overarching Truth
Our Linux environments are just as vulnerable as any other environment. All of these misconceptions around Linux security fall short because they do not take into account what history has taught us, that breaches do happen.
In order to have a healthy security posture, companies need to grow beyond the idea that all breaches can be prevented and address the need for visibility of the code running within their workloads.