Cloud Native Security is a cloud posture management solution. Initially, it focused on helping us understand and assess our compliance posture and cloud configuration for workloads, etc.
There are three key use cases for Cloud Native Security:
- Continuous Configuration Monitoring: This ensures 24/7 oversight of configurations and identifies any issues as they arise.
- Asset Visibility: Gain immediate visibility of all cloud assets upon deployment and ensure they are properly tracked within the system.
- Container Security: Assess vulnerabilities in Docker clusters and other containerized environments based on compliance requirements.
I have used Prisma Cloud extensively at several organizations. We have also used Wiz and Cloud Native Security. Cloud Native Security is particularly easy to use because it requires no configuration. All we need to do is create an API key that connects to our cloud account, and it will automatically start identifying all the workloads and accounts associated with our master account. We can see them all listed on our screen. Cloud Native Security does not require any configuration beyond selecting what we want to see on the screen. On the other hand, Prisma Cloud which I used until about a year and a half ago was superior in some ways. However, the amount of data it generated was very high, and it produced a lot of alerts and events. This required trained personnel who understood our workloads and specific cloud environments to manage it effectively. Cloud Native Security is a low-maintenance product. It is pre-configured and requires minimal manual setup, making it ideal for small to medium-sized teams that don't have dedicated resources to manage individual security products.
Like any other product, every incident has its own unique characteristics. Incidents are typically classified into categories of critical, high, medium, and low. This classification is based on the nature of the vulnerability, the ease of exploitation including whether authentication is required, and the potential impact. There are many similarities to other scoring systems when you consider the underlying factors and the overall environment. This system resonates with me because it considers multiple factors beyond just the Common Vulnerability Scoring System. For example, it takes into account features or passphrases that are displayed on the screen or found on devices, and how that data is stored.
The current system incorporates some internal analysis, but it's minimal. While the overall classification is likely appropriate, the remediation guidance could be enhanced. Ideally, for each vulnerability, there should be clear instructions on how to fix it. However, some vulnerabilities might be relevant to an organization's specific use case. For example, a public IP address being accepted by an SQL server on Azure might be flagged as a vulnerability, but it could be a legitimate configuration for an organization that has a specific database configuration requiring access from multiple locations.
Cloud Native Security operates entirely agentless. Using just the API key on the master tenant provides complete coverage, regardless of the cloud platform we're using. We avoid agent-based solutions for a simpler and more efficient approach.
While evidence of exploitability in Cloud Native Security's reporting might not be crucial, it would be beneficial. If a vulnerability is actively exploited, we need a comprehensive solution to analyze the information and enhance our monitoring. However, that's just our perspective. In terms of Cloud Native Security's scanning ability, I find it limited. It displays the essentials, and the module essentially fills the attack map. However, it doesn't explicitly consider the exploitability index. Despite this, the existing exploitability scoring seems adequate. If a vulnerability can be exploited on our network which is simply a local network with zero authentication required, the complexity is factored in, and the vulnerability is classified as high, medium, or critical.
We leverage the offensive security engine to identify potential zero-day vulnerabilities that might be relevant to our workloads. Additionally, it helps us assess exposed configurations or misconfigurations that could be exploited by these vulnerabilities. While this engine is a valuable secondary source of data for improvement, it doesn't replace the independent solution we used previously. We primarily rely on that solution for information specific to our environment.
There are two main approaches to IaC scanning. One involves internal and Docker security modules. These modules analyze internal container images to identify vulnerabilities. For additional scanning, we leverage other products. We use Tenable and integrate it with CI/CD tools. This allows us to scan code dynamically and analyze traffic on a one-time basis. Additionally, PingSage assists in gathering data for IaC scanning.
Cloud Native Security significantly reduces the number of false positives we encounter. Unlike some other tools, it generates very few alerts that are ultimately unimportant low noise. I've rarely seen false positives from Cloud Native Security. While some Cloud Native Security alerts might be legitimate concerns, we can also suppress them if they're not relevant to our standard operations. This allows us to configure our cloud environment to focus on the most critical alerts.
Cloud Native Security has had a positive impact on our risk posture. As our only CSPM solution, it helps us with asset discovery, critical asset monitoring, and configuration issue detection and remediation.
Cloud Native Security has significantly reduced our average time to detection. Detection is almost always achieved in a single instance. We've confirmed this through multiple tests. The longest detection time we've encountered is around three to four hours. This extended timeframe occurs because the scan isn't running continuously. Instead, it operates at specific intervals, periodically examining our infrastructure and performing analysis. Consequently, the detection speed depends on when the misconfiguration happened relative to the next scheduled scan.
Our remediation process is entirely internal. Servers deliver the fix based on the severity assigned by Cloud Native Security, which is directly related to the vulnerabilities found. We then use our internal analysis to consider the environmental configuration. If the vulnerability is a zero-day in the user acceptance environment, we delay remediation until a later time. However, if it's found in the production environment, we address it immediately. We also prioritize remediation based on importance, so we see alerts related to production or pre-production instances first. The remaining vulnerabilities are addressed afterward.
Cloud Native Security has had a positive impact on our engineering functions, such as DevOps and the cloud infrastructure network team. It fosters a collaborative environment where teams can address alerts independently. This empowers engineers to take ownership and resolve issues promptly. DevOps is our primary user group, and Cloud Native Security helps them manage infrastructure, network, and CI/CD deployments efficiently.
Collaboration helps save time, particularly in engineering tasks related to infrastructure and technical deployment, rather than in development itself.
Cloud Native Security offers attack path analysis. This feature analyzes a combination of vulnerabilities, misconfigurations, and load balancer configurations to predict potential attack scenarios. This comprehensive picture helps us make informed investment decisions and determine appropriate security controls.
We requested additional capabilities as we began deploying and scanning beyond the initial setup. Specifically, we wanted the ability to:
- Continuously monitor configurations 24/7.
- Gain immediate visibility of all assets as they are deployed and ensure they are included in the system.
- Identify underlying configuration issues.
Another valuable enhancement is compliance management for various standards like ISO, PCI, HIPAA, GDPR, etc. As organizations move to the cloud, a cloud posture management tool that offers complete cloud visibility becomes crucial for maintaining compliance.
One area for improvement could be the internal analysis process, specifically the guidance provided for remediation. While the classification system itself might be industry standard, the remediation steps could be more specific. A vulnerability might be critical according to the scoring system, but its urgency depends on the context. For instance, a critical vulnerability signed by Cloud Native Security or any other product might be less urgent if it affects a non-production development environment undergoing UAT compared to a production environment.
I have been using Cloud Native Security for almost eight years.
Cloud Native Security is a SaaS product and I've never experienced an outage. It's highly reliable and available whenever we need it. They have scheduled maintenance, but it's infrequent, typically only happening once or twice a year. Whenever there is maintenance, they provide advance notice, just like any other OEM would do.
Scaling Cloud Native Security is straightforward. Creating a dedicated API team is the primary step, and this typically takes around five to ten minutes. Within a few hours, we'll see feedback integrated into our Azure and AWS consoles, along with the configuration of new alerts. Scalability is no longer a concern because Cloud Native Security is a fully cloud-based resource. This means it's elastic, with access to a vast amount of computing power and storage on the backend.
Their technical support has become very reliable. They have grown from a small team to a large one, and initially, the founders themselves would handle deployments. Now, they have dedicated Customer Success Managers and configuration automation tools to ensure smooth deployments. Even if they don't have an immediate resolution to our problem, the team actively investigates and works on solutions.
In the past, I've used Prisma Cloud and Wiz. While they were functional, Cloud Native Security offers several advantages. It's very cost-effective and requires minimal configuration, making it a great fit for my needs. As I move between companies, I'm always happy to recommend Cloud Native Security to new employers.
When evaluating security products, there are several key factors to consider. Return on investment, initial investment cost, and built-in functionality are all important. Cloud Native Security excels in these areas. Their licensing model is based on the number of integrated accounts, rather than complex metrics like nodes, clusters, or data volume. This simplicity makes Cloud Native Security easy to use and manage. Additionally, it offers faster performance compared to other solutions I've used.
The deployment process is quick, taking only about five minutes. We simply need to meet with Cloud Native Security for setup. They will then guide us to the main portal and create an API key for us. On our end, we'll enable the key in our administrative console, whether it's Azure or AWS. Once that's done, the initial discovery scan will take approximately 90 minutes to two hours to run. After that, we'll start to see updates appearing in the portal.
The implementation was completed in-house.
There are different pricing models for software licenses. Some models are based on the individual number of assets a user has. Others consider the number of nodes, clusters, and accounts, with different pricing for each factor. I've also seen models that use the number of deployed APIs, endpoints, agents, or users. From what I've seen, Cloud Native Security seems similar. Their pricing appears to be based simply on the number of accounts we have, which is common for cloud-based products. This simplicity makes their pricing straightforward and potentially cost-effective.
I would rate Cloud Native Security an eight out of 10.
While components like cloud configuration, central security, and management volume boast zero maintenance, we do encounter situations with Kubernetes. Occasionally, security issues or container-specific security problems might cause the cluster to disconnect. In these cases, we need to manually intervene by running a batch script to re-onboard the cluster. This is the only instance of internal maintenance required.
Before implementing Cloud Native Security, organizations should consider the specific security challenges they're facing. For organizations that are at least 80 percent cloud-based, a CSPM solution becomes essential. Even for hybrid organizations with on-premises and cloud components, cloud security offers advantages in terms of maintenance ease, reliability, and cost-effectiveness.
Key Considerations When Choosing a Security Solution:
- Use Case: What specific security risks are you trying to mitigate?
- Objectives: What are your security goals?
- Incident Response Needs: Do you require detailed event logging and extensive incident response capabilities?
Matching Use Cases to Solutions:
- Customization: Cloud Native Security excels in customization and can be tailored to meet specific needs. It's ideal for teams lacking extensive cloud security expertise to establish and refine security policies. While some organizations, including both large and small ones, might not require this level of control, it remains a valuable use case for others.
- Targeted Security Features: Different use cases call for different security features. Container security or vulnerability management might be your primary concern. In some cases, Cloud Native Security's vulnerability management can be used as a complementary solution alongside a more comprehensive primary tool.
Ultimately, the decision comes down to your specific needs and deployment model. Don't get caught in the trap of seeking a one-size-fits-all solution. Consider your security team's capabilities and whether Cloud Native Security can truly replace them or if it would function best as a complementary tool.