PANCast™ Episode 30: What is Runtime Defense Protection?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
L4 Transporter
No ratings

 

 

Episode Transcript:

 

John: 

Hello, and welcome back to PANCast™. In today's episode, we will discuss 'Runtime Protection' and we have a special guest. Now Akshay, as you are joining us for the first time on PANCast™, could you start by telling us a bit more about yourself?
 

Akshay:

Hello John, firstly, thank you for having me on this PANCast™ today. I am Akshay Rastogi and I am a Staff Technical SupportI am Akshay Rastogi and I am a Staff Technical Support Engineer in the Prisma Cloud Compute team with years of experience in Cyber and Network security.  I am a security enthusiast and always look forward to learning new technologies.I am Akshay Rastogi and I am a Staff Technical Support Engineer in the Prisma Cloud Compute team with years of experience in Cyber and Network security. I am a security enthusiast and always look forward to learning new technologies. Engineer in the Prisma Cloud Compute team with years of experience with Cyber and Network security.

 

John: 

Thanks Akshay, now the topic for today is Runtime Protection. Can you tell us What Runtime Protection is and why we need it?
 

Akshay:

So runtime protection is one of the features of Prisma Cloud Workload Protection Platform which involves monitoring and protecting workloads as they run in the cloud computing environment, defending them against attacks and unauthorized activities in real time.

It uses techniques like behavioral analysis, machine learning and signature-based detection. It integrates with threat intelligence feeds for up-to-date threat detection.

 

John: 

What do you mean by workloads?
 

Akshay:

By workload I mean databases, applications, batch jobs, user requests which might be hosted on various platforms or resources, such as AWS EC2 instances, Microsoft Azure’s VMs, Google Cloud’s containerized applications, or Serverless Functions.

And each of these workloads presents a potential attack vector for threat actors. So every workload that performs a service, regardless of how briefly it’s operational, could be targeted for attack. This is where runtime protection comes in.
 

John: 

Can you give us some details on how the runtime protection works?
 

Akshay:

Well, Runtime Protection works independently for all these types of resources. Though you would notice that the feature set like Filesystem, Process and Network Protection are more or less same for these resources, however, the way the data is processed varies.

For Container resources, Runtime creates something called a ‘Container Model’ for each image which is a unique 1:1 relationship between models and images. It does so by using machine learning and behavioral analysis that are Static and Dynamic in nature.

For other resources like Host, App Embedded and Serverless, it does not create any model and instead directly monitors the workload behavior and takes action as per the configuration. Runtime does create an observation deck for Host and App-embedded which one can find under Monitor Runtime. This may help admin understand the workloads and therefore, configure their respective runtime policy rules.

 

John: 

OK, so how will this help the admins to protect their workloads?
 

Akshay:

There are feature sets as mentioned earlier such as Filesystem, Process and Network Protection available for different resource types and are designed to keep in mind the behavior of these resources. For example, the resource will have running processes, it will be making connections IN and OUT of its environment, it will try to perform different filesystem related operations and these could be malicious.

Admin will have information about these operations and can decide what action it wants to take such as Allow, Prevent, Block or just want to generate Alert.
 

John: 

Now we understand what the runtime protection does, so how can one take advantage of this?
 

Akshay:

So the runtime protection feature is already simplified as it is divided into different sections on the basis of type of resources such as Containers, Hosts, Serverless Functions, or App-embedded.

Each section controls the activities for its respective workloads. That could be as per the manual configuration added by the admin or by the model created by Prisma Cloud Runtime engine.

For example, if an Admin wants to create a runtime container policy then the admin should first understand what Prisma Cloud has learnt about the containers by looking at the container model and then can configure Runtime Rules for the Container Policy.

For each model entry, admin will find one of the model status which can be Active, Learning, Relearning or Archived.

You can find the details of these status in the Prisma Cloud Admin Guide.

Admin can open the container models for a specific image entry and then look at tabs to understand what has been learnt for different feature sets.

So let’s understand with an example: if the container is running a ‘busybox’ app or CMD '/bin/bash' as a part of the image, then that will be added in Static Analysis when the container is loading for the first time.

Now if a user runs another process manually or it is a subprocess of a process user executed then that will be recorded in Dynamic Analysis. Good example is performing 'apt-get update'. You will see so many processes/filesystem changes being recorded as apt-get will try to make those changes during installation and update.

All these learnt details work as an 'Allow list' and then you can configure rules to tweak this behavior.

So, a simple concept to remember: Container model -/+ configured rules = Allowed Behavior.

Similarly, for Host and App Embedded, admin can look at their respective observations to find details such as Apps Names and their startup processes and then accordingly configure runtime policy.

 

John: 

What are the different use cases where runtime policy provides protection?
 

Akshay:

There is an extensive list of features for all of these resource types. Let’s try to understand a few.

You can take actions such as Alerts, Prevent and Block. Prevent is when you do not want the execution to occur and Block is when you want to shutdown the workload altogether.

Let's take an example of Process feature: Let's say you do not want the user to execute 'curl' or 'wget', then you can use a Prevent effect which will throw an error when a user executes it. Similarly, the Block effect will terminate the container.

Another example is, if you want to generate an Alert if any Crypto Miner process is executed or a crypto miner socket is initiated, then select Alert effect.
 
Or you want to terminate a container when a process such as 'netcat' is executed which can be used for Lateral movement then use Block effect.

Please note, there might be some processes that might not trigger prevent action. It might be due to the fact that those processes are very short lived, like 'ls', pwd'

Similar to process, we have:

  • Networking, which monitors network activity from the containers.
  • Then we have DNS Monitoring, which analyzes DNS lookups from running containers. You can explicitly allow or deny domains.
  • Then we have File systems, which monitors and protects from any change in files which are not a part of the learnt model like changes in SSH configurations or certificates and many more. It can detect the presence of malware. For Malware, it uses Intelligence stream to compare the MD5 of the files with the MD5 database of Malicious files.
  • Even if all these rules and models don’t capture all of your scenarios, you have 'Custom rules'. Custom rules help you take specific action by analyzing behaviors using 'expressions grammars'.

For example, you want to Alert if a process name ‘P1’ is trying to be executed or if the process command line has 'P1' in it; then you can write a rule and add an Alert effect to it.

Similarly, there are variables that one can use in the message field and this will be added in the message section of your audit events.

This is just an example of a process event. We have different sets of attributes for file systems and networking events too. You will find different examples in the admin guide.

While configuring these custom rules, make sure that these rules don't overlap with other feature set rules as the Custom Rules takes preference.

Also, custom rules don't take preference in case of Crypto miners as crypto miner detection is dynamic. Runtime engine follows some set of checks like resource utilization, C&C connections along with md5 to detect a process/file as a crypto miner.

Please note, these are just a few examples of what these features provide.

 

John: 

Now we have created rules, how can we monitor these activities and troubleshoot if something doesn't work as expected?
 

Akshay:

Sure, we do have many dashboards which can help you find the incidents and provide great details on what has been executed and in what category that incident falls. Let's discuss few of them:

There are individual monitoring tabs for these resources under Monitor 'Runtime'. This is where you will find a Container Model, Host and App-embedded Observation. You will get information about what is learned about the containers like processes executed during learning hours, connections initiated to Ports or IPs, changes made on the file system and so on.

Then you have an Incident Explorer. This single incident dashboard will show you the incident details, what was impacted, you can see the different stages on the workload using 'forensic' and It will show you the Radar view for all the connections to and from the workload.

Then you have Runtime Audits under Monitor --> Events. It will have audit data which includes the message for the Event, Effect, Event type, User, and rule through which it is generated.

Last but not the least, the 'Defender Logs'. This gives you the similar details as the events with few extra details like when the rules were pushed onto Defenders. I would request you to listen to our interesting PANCast 'The Importance of Making Use of Defender Logs' to learn more.
 

John: 

Great info Akshay, so what are the key takeaways for today?
 

Episode Key Takeaways

 

Akshay:

  • Use runtime protection whenever you would like to detect and protect actions executed on running workloads.
  • Look for a container model or Host and App-embedded observation to understand what is learnt and observed about the workloads.
  • Make use of custom rules if machine learning hasn’t picked up the required use case.
  • Last but not the least, Troubleshoot and Detect activities by using Individual Monitoring tabs, Event Audits and Defender logs.
 

John: 

Thank you again Akshay. I hope our listeners have learned a thing or two about Runtime Protection. For our PANCasters out there if you’d like the transcript of this episode please head to live.paloaltonetworks.com.

 

Related Content:

Prisma Cloud 

Rate this article:
(1)