Prisma Cloud - Azure Scan Frequency and Config change detection

[nugentec]

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!!

[SRohatyn]

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.

[nugentec]

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?

[SRohatyn · Accepted solution]

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.