Enhanced Security Measures in Place:   To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.

Prisma Cloud - Azure Scan Frequency and Config change detection

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Prisma Cloud - Azure Scan Frequency and Config change detection

L1 Bithead

Hi, I'm using the Prisma Cloud (previously Redlock). Is there a way I can change the frequency of the scans to check for misconfiguration. Also where can I check the current frequency. Does the scan run every hr or every 24 hr. Is it the same for AWS/Azure/GCP? Also if someone makes a mistake and changes the resources while the scan is going on and then corrects the mistake, will the scan detect what happened during the scan? If I made a blob public during the scan and made it non-public again before the scan finishes, will the scan result show no issues or will it say that changes happened during the scan which were fixed?

Thanks!!

1 accepted solution

Accepted Solutions

I will split that into 2:

Audit events are point in time of actions that were made; so if it's in the Cloud Provider's audit logs, we'll catch it when we scan. These are not going away anywhere.

 

Config changes: this is highly dependent on many causes.

If we just got the bucket output from its API, then till this scan finishes on that account, we have a specific status on the bucket from that API. Once we touched it, other changes should only be known to us in the next scan.

 

I hope this helps.

View solution in original post

3 REPLIES 3

L2 Linker

Hello @nugentec 

 

The scan of the entire cloud providers environment is somewhat continuous, as we constantly compare current status of the environment to what we know about it and thus scan the differences.

The scan process compares info, grabs updates data, checks policies that are enabled and create alerts.

This entire process can take between 15-60 minutes, depending on the environment load, how many APIs are needed to run and throttling on the cloud provider. This is the high level time frame.

 

This cannot be changed in the UI as a scan schedule and thus cannot be viewed by the Prisma Cloud user.

 

Thanks @SRohatyn! That helps a lot.

 

Any idea about the second part of my question?

1) Start -> S3 bucket is not public-write-able

2) Config Audit starts and does not report any incident

3) During the config audit scan, the user enables public writes on S3 buckets

4) Before the config audit finishes, the user makes the S3 buckets not public-write-able again
5) Will the Config audit show any incident after it completes? Or will it be oblivious to the fact that changes were made during the Config Audit?

I will split that into 2:

Audit events are point in time of actions that were made; so if it's in the Cloud Provider's audit logs, we'll catch it when we scan. These are not going away anywhere.

 

Config changes: this is highly dependent on many causes.

If we just got the bucket output from its API, then till this scan finishes on that account, we have a specific status on the bucket from that API. Once we touched it, other changes should only be known to us in the next scan.

 

I hope this helps.

  • 1 accepted solution
  • 7698 Views
  • 3 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!