Site Search

I tried implementing Prisma Cloud's CSPM Part 2: Investigating problems from visualized alerts

Last time, I wrote about registering the cloud account used by my team in Prisma Cloud and enabling the policy.

Just activating the policy does not raise it as an alert, so this time we will set an alert rule for that policy and deal with the policy violation alert.

Specifically, as a result of detecting policy violations, we will describe the investigation and countermeasures for the content displayed as violations related to Audit Event (*).

*Logs recorded in CloudTrail will be displayed as Audit Events when captured by Prisma Cloud.

1. View all enabled policies as alerts
First, as shown in Fig. 1, let's raise an alert for all enabled policies and see if there are any problems.
Figure 1. Alert generation with all policies applied
Figure 1. Alert generation with all policies applied
2. Check Dashboard (SecOps)
Prisma Cloud has Dashboard (SecOps) as one way to check the occurrence of alerts on the GUI.
We'll take a look here first.
Review alerts from the last 24 hours to see how much you've had to watch recently. (Figure 2)
Figure 2. See alerts for the past 24 hours by setting the Time Range to Past 24 Hours
Figure 2. See alerts for the past 24 hours by setting the Time Range to Past 24 Hours
There are 205 cases and 172 cases of High.
Due to the small number of people operating this cloud account, we did not expect to see so many violations.
We'll see what happened.
First of all, if you look at the lower left “Alert by Policy Type over Time” in Figure 2, the color is almost the same.
There is also a possibility that there is some kind of attack due to the large number of Audit Events.
Let's look at the events during the time when many Audit Events are occurring to see what is happening.
Let's click the bar graph from 18:00 to 21:00 in Figure 3.
Dashboard(SecOps)の確認
Figure 3. Alerts by Policy Type over Time showing only Audit Events
3. Alert investigation
If you check the actual events, you will see a lot of DeleteNetworkInterface events. (Fig.4)
Figure 4. Mass DeleteNetworkInterface
Figure 4. Mass DeleteNetworkInterface
Since the network interface deletion API is being continuously executed, there is a possibility that it is being attacked from the outside in some cases, so we will investigate whether this is an attack. First, check from Resource Config what is being erased.
Figure 5. Check Resource Config
Figure 5. Check Resource Config
Looking at the Config, I found that the region was us-east-2 before what was deleted. Since it was a region that I didn't usually use, I wasn't even aware that resources were being generated here.
When I actually switch the region from the management screen and display ECS, there is a cluster that I do not know, and it seems that the service keeps failing to start up.
Due to this failure to start the ECS service, the network interface is automatically deleted, and ECS continues to retry to start the service, so the above behavior is occurring.
In order to deal with the Cluster where this problem occurs, let's check the Prisma Cloud log to see who created this behavior for the Service.
When you navigate to the Investigate section, a search Box appears and focusing on it will show possible entries.
Figure 6. Autocomplete in Investigate search Box
Figure 6. Autocomplete in Investigate search Box
You can search the details of the log recorded in the Audit Event with “event from”, so try to find out who created the Service in that Region a little before the period when the problem started to occur.
Candidates are output for values that can be entered below "event from". This time, when I searched with the following content, I was able to identify the user who most recently created a Service in us-east2.
Figure 7. Finding the user who created the Service
Figure 7. Finding the user who created the Service
After interviewing the relevant user, we found that the failure to start the Service was not intended in the Cluster that was set up for testing.
The operation may not be normal, but since the Cluster was created in a Region that was not originally intended to be used, I asked the creator to delete the entire Cluster that started this Service, and use it in an appropriate Region in the future. I requested
The creator contacted me about the deletion, and I was able to confirm that it was actually deleted, so I'd like to say that I'm relieved, but I don't like the situation where ECS and instances are being created without permission. .
After that, by extending the investigation period, further investigations such as checking the repair plan and past problem occurrence status from the Assets screen were found to be in violation of the CIS benchmark compliance from the instance created earlier. I'm taking measures, but it's getting longer, so I'm going to write it separately.

Summary

Just by registering account information in Prisma Cloud and checking it for a short period of time, we could see ECS information that was not visible before the improper setting, and found that we were not properly prepared.
As with ECS this time, stray VMs can also be a security risk, so in order to understand the operation status of resources in the entire cloud and detect suspicious behavior, we use Prisma Cloud and other CSPMs. We found that monitoring the state of the cloud by using the

Related video: "Achieving Secure Application Development -Improving Security Baselines with Posture Management-"
Providing a secure work environment for employees is a common challenge for all businesses. Suppression of security incidents is also recognized as a major issue in application development sites, but there are situations in which developers have to lower the priority of security due to unique reasons, and the importance of security is neglected. is not uncommon. In this session, we will explain Posture Management, a preventive solution for implementing the minimum mechanism necessary to reduce the probability of security incidents in the development environment and significantly improving the security baseline.

Inquiry/Document request

In charge of Macnica DevOps

Weekdays: 9:00-17:00