Average mean times to respond (MTTRs) is a typical metric for SecOps measuring their effectiveness to recognize and respond to security incidents in their environment. For 67% of organizations, MTTR takes fewer than 24 hours and that percentage rises to 95% when MTTRs above 30 days are omitted. Excluding the outliers, the situation might seem to be relatively under control.
Nevertheless, the average time an attack goes unnoticed before a response – mean time to know (MTTK) or dwell time – paints an entirely different picture. Although estimates vary by source, most place average MTTKs at approximately 15 days – up nearly 30% from 2021 – and this number rises to 51 days in small-to-medium enterprises. Additionally, attackers are becoming more efficient along certain vectors as port scanning tools, like Masscan can now detect misconfigured containers in an average of just 5 hours.
The time it takes to resolve an issue is not usually awareness, or developing and verifying a fix. Rather, MTTR is dominated by the effort to fully understand the scope and impact of the issue. The challenge for DevOps Site Reliability Engineers and Platform Engineers charged with investigating an issue is creating a picture of what has happened from incomplete data. Cloud platform audit logs, application and system logs, etc. are challenging to review and correlate, assuming any logs were even captured. With the MTTK for organizations measured in weeks to months and the time it takes attackers to cause damage and exfiltrate data measured in mere hours, it explains why cloud and container attacks continues to be on the rise when successful attackers can expect weeks to perform reconnaissance, find sensitive targets, and implement backdoors, all before actioning on their objectives such as cryptojacking, data exfiltration, or ransomware. What kinds of capabilities do DevOps and SecOps teams need to reduce MTTK, and where in the left-to-right spectrum of development would those capabilities apply?
MTTK and Runtime Visibility
Unlike most security performance metrics, MTTK doesn’t measure an organization’s capacity to prevent attacks from happening. Rather, it indicates what kind of visibility you have into your runtime environments. A high MTTK would suggest that there are challenges to view what is actually happening within and across cloud and container workloads.
There are many reasons for poor runtime visibility in today’s increasingly multi-cloud environments. Organizations run workloads on various third-party cloud services that lack shared monitoring tools. Containers get raised and destroyed faster than everyone in the development cycle can communicate or enforce protocols. And traditional Linux system activity auditing tools, such as AuditD, cannot even see containers, much less monitor them.
Crushing MTTK with Spyderbat
Creating the kind of system-wide visibility – in multi-cloud architectures and the containers spread within them – requires digging deeper than traditional monitoring tools and ditching the practice of trying to reassemble the whole picture from various uncooperative parts. To this end, Spyderbat has developed a solution of tapping eBPF technology into a next-generation runtime security tool. As eBPF allows system-level monitoring without altering the kernel, it provides an ideal bedrock foundation for efficiently creating visibility and achieving real runtime monitoring.
Spyderbat deploys a lightweight Nano Agent that extracts eBPF data – representing all system and network activities in all clouds and containers – and securely transfers it to Spyderbat’s SaaS backend avoiding performance degradation on the host systems. Spyderbat assembles every activity into a Universal Causal Graph (UCG), capturing the causal relationship (e.g. Process A spawned Process B, Process C received an inbound network connection, etc.). With the UCG, Spyderbat monitors workload runtime behaviors in real time, and keeps a historic record. Spyderbat adds security context by flagging unusual activities or known MITRE ATT&CK techniques, creating a “Spydertrace” connecting every activity causally related to a security context flag, including other flags. This allows Spyderbat to recognize the early indicators of a real attack, with full visibility for DevOps and Platform teams to immediately see the initial entry point or root cause from the causally related chains of activities and the entirety of its impact or scope. With the ability to discern real attacks from harmless irregularities in real time, your team’s MTTK, and therefore MTTR, capabilities are drastically reduced, allowing DevOps teams to remain more productive.
To learn more and schedule a live demo, contact Spyderbat today.
Write a comment