Context matters when it comes to cloud security
Those of us in DevOps and IT Security are drowning in lists reporting potential issues. Here it comes: my daily list of vulnerabilities found in my IaaS environment yesterday. And here’s my list of potentially risky configurations. I might also get an occasional compliance posture list to look at. These lists based on yesterday’s findings don’t give much context and don’t provide a map to identify how important the resource is that is associated with the issue.
Nobody has unlimited time. I have to look at a list and pick an item to investigate, then I need to find the container/namespace/cluster/VM/whatever and try to figure out the context of this resource to decide the importance of this vulnerability or configuration issue. It’s an impossible task at scale in a runtime environment.
I can’t whack-em-all. There are too many. I have to decide quickly what to fix and what NOT to fix.
Lists of Vulnerabilities – what is important in context?
My vulnerabilities list labels each issue as critical, high, medium, and low. It seems logical to prioritize anything labeled as critical over anything not labeled critical. So I sort my list and tackle the ones labeled critical. Without any further context, I could use up my valuable time chasing down critical vulnerabilities that are in images in isolated services that don’t touch any sensitive data.
No, thank you. I don’t want to spend all my time on these issues if I don’t get to vulnerabilities buried further down in my list (maybe only labeled as high or medium) that are in images used in critical, highly connected services that store or process data that’s valuable intellectual property.
Lists of Misconfigurations – what is important in context?
My list of risky configurations likely also has a severity rating (low, medium, high) associated with each finding. And I might take the same approach here, spending my time investigating what is labeled high and leaving lesser severity issues for later (or never). But what if this approach results in me not investigating a medium or low severity misconfiguration for a workload that’s part of a critical service that accesses or stores privacy regulated data like payment card information?
Time context also matters
Yesterday or even a few hours might as well be 100 years in IaaS time where a container or a virtual machine lifespan is only measured in minutes. A list of vulnerabilities or risky configurations discovered yesterday or even four hours ago, is already old news. If your environment is attacked and compromised, it’s already over by the time you get yesterday’s list of issues. That list serves as a post-mortem of what you already should have done if you had only known to do it in time.
Everything in context and in runtime
Instead of playing whack-a-mole with yesterday’s lists of security posture issues, we need a runtime, system view of workloads and microservices.
What’s needed is a Cloud Native Application Protection Platform that provides:
- A view of your running networked environment of microservices with their current security posture of vulnerabilities and configurations graphically displayed so prioritization is clear at-a-glance.
- A view of containers and instances in the graphical context of your system architecture that includes if they are storing or processing sensitive data that must be protected so prioritization is clear at-a-glance.
- .Continuously updated posture findings and compliance reports, not yesterday’s findings, so critical issues are identified immediately, not after the fact
Focus on what’s really important and automate everything you can
Connect your cloud environment to Microsec.ai for graphical runtime monitoring and policy-driven protection for your IaaS environments. Get up and running in minutes without installing agents and sidecars for a level of visibility, context, and protection you haven’t seen before. Contact us for a demo to learn more.