Previously, we were using AWS services, but we were not getting the alerts in Jira. When Cloud Native Security was introduced to us, we wanted it to automatically create Jira tickets, and we wanted custom alerts. These were the two areas that we shared with them, and they stood out in these aspects. We decided to take it ahead, and we have been using it for the last two years. I feel a lot of difference in the security posture development. When we share the tickets with the developers, they work on that, and we have tracking of them in Jira. We wanted to track alerts in Jira. We no longer have situations where we flag an issue and it does not get resolved on time.
We use agentless vulnerability scanning. The process that Cloud Native Security follows is that you have to deploy the cloud permission template in your account, and then it creates a role that tracks or scans all the resources and finds if there is any misconfiguration. We have integrated Cloud Native Security with Jira. It triggers alerts on Jira. A person is assigned to an alert, and the concerned person is notified. As a security team, we collect those tickets and forward them to the respective team.
Previously, we were not able to track those tickets, whereas now, we are getting automated Jira tickets. It has solved our biggest problem. We are expecting the same from Cloud Native Security in the future. We expect that it will capture the triggers or alerts. If any new security vulnerability is found, it will also flag that to us.
It provides an overview of our security posture. If a metrics endpoint is public for any domain, that gets triggered. We get reports for different domains, such as Kubernetes security and vulnerabilities management, IaC scanning, or cloud detection and response. Cloud Native Security covers all of these. There is also a graphics tool where we can get all the details in a graph. All the Kubernetes microservices get scanned in the workload protection. The Cloud Workload Protection module detects all the cluster misconfigurations and other things. It also gives you alerts on the containers. We were looking for such a tool with all the cloud security modules.
We can also create our own custom policy. For example, if we do not want to enable the recommended Cloud Native Security policies for our company, we can create our own policies. This feature is very helpful.
We use Infrastructure as Code (IaC) scanning. It follows all the features for shift-left. We get all the alerts for IaC scanning. For example, if TerraForm is not performing any security checks in the template, that gets triggered. We also get information about any vulnerabilities related to IaC.
We have not got any false positives with Cloud Native Security so far.
Cloud Native Security has affected our risk posture. It shows us our risk areas. As an organization, we look for cloud security tools that can manage all the areas, and Cloud Native Security is doing a good job in managing all the things.
Cloud Native Security has reduced our mean time to detect. The detection time of Cloud Native Security is quite good. It takes half an hour for critical alerts and one hour for high alerts. These are the SLAs that we have. The detection time is quite good.
Cloud Native Security has also reduced our mean time to remediate. We have defined our SLAs as well. In our organization, we define the SLAs and share them with the developers or the DevOps team so that they can follow them. They work on the assigned issue, and if there is any issue, they come back to us.