We are using the compliance module of the solution.
We use the solution to secure the cloud accounts in our organization that we maintain. We launched this tool for our security. We used to choose the products in the market based on the budget. Prisma Cloud was already launched and onboarded before I came to this organization. We used to onboard other tools, like Defender Cloud or Prisma Cloud.
CSPM is different from Prisma Cloud; they are two parts in a single product. For day-to-day activities, we use CSPM almost 100% and Prisma Cloud for almost 30% to 40%. CSPM identifies the alerts and misconfigurations from the account level for day-to-day activities. We inform the DevOps team to close the alert by getting the solutions from their account-level site.
We chose this product to identify the misconfigurations based on the severity level. For critical, it should be done within one or two days; for high, it should be done in three to five days. Based on the time period, we used to get these solutions in time. Sometimes, users may face many exceptions for the solution or alerts.
For example, there will be some internal ELBs (elastic load balancers) from the account level. Internal ELBs cannot be published because they'll be used internally to share the data. The policy may identify the alert from the internal ELBS also. So, we need some exceptions so that the internal load balancer can be accepted but not generate an alert from the Prisma side.
We used to change our RQL query based on the requirement. Otherwise, we approached the product or support teams to get the solution from them. They'll provide the RQL with the changes based on the requirement, and we'll get the solutions as quickly as possible. Most of the time, when there is a problem, there will also be a solution.
Maintaining an organization with multiple million dollars is not an easy thing at the market level. So, it's important to have a product that effectively identifies the issues. Nowadays, hackers send a simple link to an unknown user. When users click the link, their bank account gets hacked, and the amount gets deducted from the customer side.
When a single user gets this type of attack, an organization should be equipped to effectively identify these attacks. This product works very effectively to identify such attackers. The solution can not only help identify present attackers' thinking, but we can think about the future and customize the queries based on the attackers' mindset. We can identify the attackers' way not to get marketed in the banking sector.
Prisma Cloud is a monitoring tool that continuously monitors 24/7. It's not about getting the solution but identifying the misconfiguration. When it continuously monitors the cloud accounts, the product identifies the issues, and we get the solution.
Getting the solutions is in our hands, but identifying the issues is the product behavior. The product behavior to identify the issues is highly appreciable. Then, we get the solution based on the requirement.
Whatever automation Prisma Cloud provides to the policies is a good way to get this solution, but automating the complete tool has its positives and negatives. It's a debatable question because Prisma is not a testing tool. The tool identifies misconfigurations
The solution can't provide 100% security at the market or organization levels. If we secure a product by 99%, there is still a chance of a one percent attack. So, there should be some monitoring as well as automation. However, going for only automation or monitoring is a debated question.
We continue using Prisma Cloud because we are 100% satisfied with it, not only from my side but also at my organization level. In my organization, we started a gap analysis. We are maintaining more than 150 AWS cloud accounts. So, there are a lot of alerts for misconfiguration from the product level.
Since January, we have started one requirement to reduce the alert. We collect all the alerts in an Excel sheet, and we used to share with the DevOps HOD that these are the misconfigurations for your account. Then, the HOD used to share the sheet with the team members.
I can proudly say that we started with more than 8,600 alerts for all the cloud accounts in the month of January. Now, the count is reduced to almost 2,400 alerts for more than 40 sensitive policies. We identified almost 60% to 70% alert reduction. We are using Prisma Cloud effectively to identify misconfigurations and implement many more features to secure the cloud accounts in our organization.
We use 100% of CSPM and only 30% to 40% of the CI/CD pipeline, like Prisma Cloud. For CSPM, I'll rate it a ten out of ten. Otherwise, nine and a half out of ten because no product will satisfy a customer 100%. So, nine and a half out of ten for CSPM to secure the cloud accounts internally or prevent getting attacked by attackers. I would definitely recommend this product.
We will launch CI/CD like Prisma Cloud in the future, and the organization should also consider the budget. Prisma Cloud is a little high-budget affair. Prisma Cloud is a mandatory tool to identify the CI/CD level vulnerabilities while doing email scanning only. Our time will not be wasted by using this tool.
If we do not scan an image for vulnerabilities while deploying a code into it, it's a waste of time deploying a code that any attacker can handle. This product identifies the vulnerabilities by email scanning only, which helps to have more time for the DevOps team to get more deployment.
We used to suggest new thoughts on how it can be more user-friendly. There is an API with which we can share our thoughts. It should be selected by other users and business organizations using the product. If more people suggest that option after we launch that thought into the API, the Prisma product will think about that thought. If it is valuable, they should definitely get this solution.
Currently, we can identify the misconfigurations based on the list of policies. Suppose five to ten members work with Prisma in an organization. In that case, they cannot go daily to the dashboard and identify all the misconfigurations singly or as a group.
We suggested a new feature: a list of misconfigurations should be identified based on the user, either a single user or a group. If three members work with a particular cloud account, then those three members should create a group, and that account should be added there. This will also reduce the time of a customer working on the product.
Whatever DevOps requirement was not presented in the product, they used to discuss it with our team. If it is a requirement we need in our organization, then we will go to the product team and tell them it is a requirement from our organization level for the DevOps team. If it is a proper requirement, the engineering team will work based on it. The product team comes up with new ideas. Since the recent launch is a better version for the product team, we also used to launch the better version from the product team.
it works both ways. Whatever new features the DevOps team suggests, we discuss them with the product team. When the product team suggests new features to help the organization, the same can be discussed with our internal team. Our manager will discuss it with the HODs of the DevOps team. If it is a genuine requirement, we will try to convince the DevOps team, and based on their approval, we will launch that feature.
It's highly recommended since the dashboard is very user-friendly. The Prisma Cloud tool is integrated with Jira. Whenever any alert is generated, it will automatically trigger Jira based on compliance. It will work based on the compliance we onboarded to Jira. We used to create compliance for Jira and day-to-day activities, like generating reports based on the accounts.
Prisma Cloud is a user-friendly solution. When managing more than 50 cloud accounts, we can get the issues and misconfigurations from the single account level, the group account level, or the total account level. We can get everything based on our requirements. The solution will secure all the cloud accounts, a single cloud account when there are multiple cloud accounts, or a group of cloud accounts based on complete requirements.
Whenever we have some issues, we approach the product team to get this solution. Recently, we faced some issues with the policies tab, which we use to create policies, and the investigation tab, which we use to create a new RQL. Whatever RQL query is implemented, there is no point in creating all the RQL queries to a policy. We get the data by creating an RQL query, and we create a policy to monitor the product. The count should match when there is a single RQL query from the investigation type and the policies tab or alert tab.
Recently, we faced an issue with a mismatch between the alert tab count and the investigation tab count. We approached the product team, and they suggested the solution within a very short time. There were some issues with the pipeline, but they fixed that bug within no time, and we got a 100% solution from them.
Three to four teams are working with a single product. The security, SOC, and DevOps teams are working with the product team to identify the misconfigurations in their environment. It's not just a single person who identifies the issues from service or product levels.
The DevOps or SOC team may identify an issue and inform our security team. Also, we may find some issues and inform the product team. A combination of all groups will work to identify issues and ensure that the product will work effectively. So, all the things will happen in a single process.
We have to close cases within a specific period based on the severity. Critical cases should be closed within one to three business working days, high-severity cases within three to five working days, medium-severity cases within five to eight working days, and low-severity cases within eight to fifteen working days.
We use some budget for the product based on the agreement. Besides that, we save a lot of money compared to the security level. I'm not talking about the product level. Product-level money is different based on the agreement. In the last one and a half years that I started working with this product, only one time without a product level or service level, we entered some credits by enabling some policies. If we have some knowledge of the product, almost 95%, there is no waste of money.
Prisma Cloud is a completely user-friendly product. The product is highly recommended for the cloud environment level. Whatever requirements we have, we can get by creating a new RQL based on our requirements. It is not only related to work. Whoever works with cloud security in an organization is greatly noticed.
If someone identifies an issue in your work, you'll remember that person. In the same way, when I notified some issues from the cloud account level, I used to interact with the entire DevOps team, not only a single person. The product helps you get more recognition.
Previously, we used the solution globally. However, because there may be a chance of data being made publicly accessible, we are currently onboarding only on the internet from the Prisma site. This secures the data and prevents it from being made publicly accessible.
I would recommend Prisma Cloud to other users or organizations looking to secure their organization in any cloud environment without budget constraints. I'm only talking about AWS because we have an AWS environment, but the solution can secure any cloud account effectively.
Overall, I rate Prisma Cloud a nine out of ten.