Another Orchestrated Attack: How Do I Protect Myself?

Criminal groups are always trying to make money by taking advantage of software vulnerabilities. In many organizations, it is difficult for security teams to keep up with attacks due to challenges on many fronts, including:

• New vulnerabilities discovered every day: There are always new vulnerabilities that need to be patched in the libraries and applications organizations use. At times, there are hard dependencies associated with vulnerable software versions, which makes it difficult or nearly impossible for IT teams to react quickly enough to upgrade or patch them.
• Unpatched vulnerabilities: Some vulnerabilities can go undetected or unpatched for a long time, especially in closed-source software. These undetected vulnerabilities are called Zero-days because they are previously unknown by those who are able to fix them. Even when they are being actively exploited, an organization requires someone with sufficient expertise and interest to be able to raise the flag and/or fix them.
• Complex attack prevention: Zero-day attacks don’t exploit known vulnerabilities and require Zero Trust runtime protection to prevent exploits. For security policies to be efficient against Zero-day attacks, they must be accurate, and traditionally this has been a challenge. Accuracy requires knowledge of how the application works and the ability to translate this knowledge into a language your security platform understands.
• Competition for talent: In a very competitive IT market with high mobility, finding and keeping the right Cyber Security experts can be difficult and take a long time — time others can use to mine cryptos with your infrastructure, making your operational costs even higher without you noticing it until it’s too late.
• Buzzwords: It isn’t easy to choose the right security product for your container environment. Vendors and security experts discuss the same concepts but often with different jargon and meanings. Often, you can’t find the truth until you try the product or read the fine print.
• Hard-to-use products: Security products can be very complicated to implement, increasing the burden on your teams. This can lead to decreased motivation because it turns security into a hassle rather than a solution.
  Often the best solutions are those that Keep It Simple (and) Secure (KISS for security 😉).
• Reactive security: Container and Kubernetes platforms are new attack surfaces. Many DevSecOps security tools only focus on monitoring and detecting bad things that happen inside the clusters but not on proactive protection, leaving users with a long list of logs and alerts to sort through to find out how to stop the attack. Due to the dynamic nature of Kubernetes, this can be a lot of fun on a Saturday night. It’s always better to stop attacks at the network level and prevent them from reaching the applications.

When looking at applications running on Kubernetes, there are two main entry points for attackers:

• The supply chain, where if any part is vulnerable, the attackers can exploit it to plant malicious binaries or backdoors in the code so that when the container is deployed, they are able to gain remote access.
• The network. A pod (one or more containers) runs in an isolated environment, so there is no interaction possible with other processes outside of the pod, limiting the interaction with the outside world to mainly the network.

NeuVector can protect the supply chain, but in this post, we are focusing on runtime protection, and protection at the network level is one of the areas where NeuVector excels. It can not only understand network layers 3 and 4 but also many application protocols at layer 7.

Know your enemy? Yes, but most importantly, know your applications.

The best way to avoid turning applications into a gateway for mining cryptos, stealing your confidential information, and installing ransomware and other illicit activities and usages of your infrastructure is to make sure applications only do what is expected from them and nothing else.

We call this behavioral-based Zero Trust:

• • Allow your application to do only what it is expected to do
  • Stop any other behavior

The Zero Trust approach saves time and elevates your security posture compared to standard container security measures, allowing you to see real attacks and application actions that deviate from expected behaviors. You no longer need to tackle an endless list of alerts (many irrelevant) or create behavior-specific denial rules.

Sifting through alerts and creating deny rules for every threat does not protect your applications effectively. Behavioral-based Zero Trust policies keep it simple and protect your application from future threats or missuses, even when the application is doing something that it shouldn’t do, and you cannot change the application.

This sounds good, but how do you get to know your applications?

Most applications have varying degrees of documentation, but often security teams do not have the time to comb through the minutia to understand the inner workings of their applications. Nor is it practical to peruse thousands of lines of code seeking answers, even if the source code is available.

This is where NeuVector discover mode comes in handy. It learns how your application behaves and then automatically creates security policy rules according to how your application interacts with the environment, simplifying container security while saving time and resources.
Here is how we create a behavioral-based Zero Trust security policy with NeuVector:

1. 1. Enable discover mode
      This step is not necessary most of the time because when you install a new application, NeuVector automatically creates a Zero Trust security group and sets it to discover mode for you, but if you want to know how to do the same using the UI, click through the following steps as the image shows:
      Go to Policy and click on “Groups”; this contains the policy groups available in NeuVector.
      The groups can be filtered by group name; In this example, the application name is ”myapp”.
      Select the group and click on Switch Mode.
      A dialog will pop up. Select ”Discover” and then click on ”Submit”.

1. 1. Start using your application
      In discover mode, NeuVector watches how your application interacts with the environment: which processes it launches, network connections, etc… and generates rules to allow them. This doesn’t have to be done manually. It can be done by automated tests you perform in your CI/CD pipelines.
      Sometimes, the automated tests are not comprehensive or don’t cover all the expected use cases. The completeness of a Zero Trust policy depends on the tests done on the application.
      For such cases, the recommended practice is to leave the application running with the initial security policy for the first time in monitor mode, where NeuVector won’t block but alert:
      
      Go to Policy and click on “Groups”.
      Select the group and click on Switch Mode.
      A dialog will pop up. Select ”Monitor” and then click on ”Submit”.Then let your users use the application for some time.We will see security events that we can review and then can incorporate into the policy by clicking through the UI as shown below:
      Go to Notifications and click on “Security events.” This contains the security events registered by NeuVector.
      Optionally we can also filter by the name of your application by typing it in the top right corner Advanced filter box.
      We click on the “Review Rule“ green box in the line for the event that we are interested in and this will show us a dialog where we can verify the allowed rule that will be deployed.
      If we are happy with it, we can click ”DEPLOY” to incorporate this rule into our group policy and allow this activity in the future.

1. Change the policy mode to Protect mode.
   We have prepared all the allowed rules needed for the application to function. Now we need to enable the Protect mode that will protect the application and, therefore your infrastructure.Go to Policy and click on “Groups”. This contains the policy groups available in NeuVector.
   Select the group and click on Switch Mode.
   A dialog will pop up. Select ”Protect” and then click on ”Submit”.
2. (optional) modify the policy.
   There may be cases where you want to restrict the policy further, for example, by limiting who can connect internally or externally to your application and on which ports. Due to the dynamic nature of Kubernetes, our network rules are created focusing on the Layer 7 protocols the application is using. In such cases, you can add specific rules or tight existing ones.

Besides the Zero-Trust policies, NeuVector also has protection against several common network attacks and threats.

This is all thanks to its unique Deep Packet Inspection technology, which allows it to drop the network packets before they reach the application, both from the outside networks as well as from other pods, so the application will not be disrupted.

And because the Zero Trust policies not only cover the network side, if this first layer of protection is bypassed, for example, the packet is legitimate, but it triggers a bug in the application, NeuVector will prevent the application from launching any other process or establishing any new connection it is not meant to.

Conclusion

• New vulnerabilities discovered every day: With behavioral-based Zero Trust policies, even if the application is vulnerable, it won’t be able to perform any action not previously allowed in the security policy. Therefore, patching becomes less urgent, allowing teams to do full testing before applying them, preventing further disruption.

• Unpatched vulnerabilities: Same as the previous point, with Zero Trust policies, we can be protected from attacks compromising the behavior of the applications we are running.
• Complex attack prevention: Thanks to the discover mode with NeuVector, we can easily generate accurate Zero Trust security policies, turning a complex task into something much more manageable.
• Competition for talent: Avoiding the stress of having to find an immediate solution to protect from an attack is a good reason for people to stay at their jobs in security. Behavioral-based Zero Trust security policies give you that extra time by protecting your application even from attacks using Zero-days.
• Buzzwords: We aren’t abusing terms such as ZeroTrust or layer seven protection. Our technology is there, and our source code is open. Anybody can try it out and see for themselves.
• Hard-to-use products: In this blog, we have seen how simple it is to create a Zero Trust policy tailored to your application via the UI. It is also possible to do the same using Kubernetes CRDs or making calls via the API. Your NeuVector policies management can be easily integrated with your existing Kubernetes automation.

• Reactive security: NeuVector not only offers the traditional capabilities of scanning, common threat detection, CIS benchmarking, monitoring and so on, as we have seen, it also allows you to create Zero Trust security policies that can stop attacks before they reach the application.
  

For more details on how to use NeuVector, please visit our NeuVector documentation page or get in touch with us.

And for more on Zero Trust, get a free copy of our new book Zero Trust Container Security for Dummies