We’ve all been hearing about the Log4j vulnerability. It’s been in the security headlines for weeks. The interesting thing about security when thinking about something like the Log4j vulnerability is that you don’t know what impacts you. For example, you may not be using Log4j directly, but you might be using an application or tool, like Selenium, that uses Log4j. Because of that, you’re impacted.

The same rules apply to say, systems in the cloud. You may not be using the hardware that’s impacted by a security vulnerability, but the hardware you’re hosting virtualized systems on may be impacted by it.

Implementing proper security practices doesn’t mean you’ll have a 0% chance of being impacted. It means that you’re mitigating as many risks as possible. In this blog post, you’ll learn about mitigating risks in the cloud, in containers, and in applications.

Security in the Cloud

The cloud is a place where people like to say it’s just someone else's server and yes, they’re absolutely right. Funny enough, there are people managing those servers, and those servers are susceptible to vulnerabilities and risks. Because of that, you’re vulnerable. To mitigate some of those cloud vulnerabilities, you have to think about a few things.

Networks

The easiest thing to do on a VPC or virtual network in the cloud is to open the firewalls rules to allow all inbound and outbound connectivity. If an engineer is troubleshooting something, it’s much easier for them to just open up everything. The problem with that is, every single piece of network traffic is now available on the system. That opens up basically every single type of attack that’s available.

Access Control

Just as easy as it is to open up systems for all network traffic, users can have administrator access to everything in a cloud console. If you’re thinking about, say, IAM permissions in AWS, they get very granular. Engineers spend countless amounts of time getting the permissions just right so X amount of people can have just enough access. However, that’s not always the case. When it’s not, your department(s) is open to many permission-related vulnerabilities. If an attacker gets access to a user account that has global admin, it’s game over.

Data

S3 buckets in AWS, Azure Storage, NAS and SAN devices in the cloud, are all an attacker's dream if they aren’t set up the right way. A lot of organizations are moving data to the cloud and that means it is far more vulnerable if say, an S3 bucket isn’t encrypted or it’s public.

Container Security

Containers (like Docker containers) by definition are virtualized units of software packaged up and deployed. Because of what they are, there are a few vulnerabilities:

• The systems that containers are running on
• The packages that containers are using
• The code running on the containers

The first piece you’ll want to think about is where the containers are running. If you’re using a Kubernetes service like Elastic Kubernetes Service (EKS) or Azure Kubernetes Service (AKS), the application security is just as important as the system security. EKS and AKS are just using EC2 instances/virtual machines, so are those systems secure?

The second piece is the packages. When you’re creating, say, a Docker image, you’re most likely using a base Docker image (like Ubuntu), running installations for packages, and copying data into the Docker image. Prior to doing any of that, you should ensure that everything that you’re bringing into the Docker image is expected.

The third piece is the code itself. You’re going to learn more about application security in the next section, but the idea is to ensure you:

• Scan code for vulnerabilities
• Know what packages you’re using in the code
• Ensure that only engineers that are supposed to have access to it have access.

Application Security

Every single piece of code has a vulnerability. It doesn’t matter if the best engineers in the world work on it. Every single application, at some point in its life, will have a vulnerability. It can be something as little as a couple of line hotfix or a vulnerability that will make or break its future. As with any security, it’s not about removing all risk (because that’s impossible). It’s about mitigating as must risk as you possibly can.

To do that, follow a few protocols:

• Implement secure Software Delivery Life Cycles (SDLC).
• Use security scanners, security linters, and security scanning tools like GitHub CodeScanner.
• Ensure no API keys, passwords, or any secrets are hard-coded into any source code.
• Check the open-source packages/libraries/modules you’re using for known vulnerabilities.
• Ensure that developers go through some sort of security training.

Although the above isn’t an exhaustive list, the list will pretty much over 80% of your concerns from an application security standpoint.

Security in Todays World

Code is code and systems are systems. Despite that fact, there are still a plethora of moving parts. Even though Linux is still Linux, the question becomes where is it being hosted? Even though code is still code, but the question becomes where is it being stored? There are similarities in security that have been around for years, but there are still several differentiating factors.

If you’ve been in tech for a while, you’ll see the comparisons between what was done 10 years ago and what’s being done today. If you’re new to tech, you’re learning this process for the first time.

Chris Ray, CISO and Security Researcher, says this about security in today’s world:

1. Know your data:
   1. Where it’s coming from
   2. Who accesses it
   3. How it’s transmitted and stored
2. Know your infrastructure
3. Follow best development practices
4. Bug bounty