Today’s software ecosystems are complex, distributed, and full of countless dependencies. When something goes haywire, getting to the core reason behind an incident can take a lot of guesswork. This is where security observability comes in.
Observability tools combine logs, performance metrics, and traces to help engineers paint a more accurate picture of what’s occurring behind an issue. Observability is the latest trend in DevOps, and for a good reason — quickly remediating failures can lead to increased reliability, safety, and customer happiness.
Now, some proponents argue that an organization’s cybersecurity footing should ideally possess a similarly high degree of observability that goes beyond the opaqueness of most vulnerability scanning processes. The idea is that more intelligent metrics into the severities around each exploit would equate to more predictable and reliable systems.
I recently met with Sandeep Lahane, CEO of Deepfence, to explore what security observability entails. According to Lahane, porting the tenants garnered from the ongoing observability movement to security can have a net positive effect, reducing false positives, and decreasing mean time to resolutions.
What Is Security Observability?
In general, observability goes beyond traditional application performance monitoring (APM) processes to collect cues that provide a deeper understanding of how an application behaves. For example, a Site Reliability Engineer (SRE) might follow logs and traces to perform root cause analysis after an incident occurs. Observability can be thought of as the “ability to infer an internal state and integrity of a system by looking at outward cues,” describes Lahane.
However, if we consider cybersecurity, to date, the practice has not yet developed a parallel to observability. This issue was apparent during Log4j, as it became challenging to precisely understand which applications were affected. “A lack of visibility and observability makes things impossible to predict,” explained Lahane. “You could look at logs, but you really need something more real-time and cybersecurity-specific.” Complicating the matters, cybersecurity signals are typically exchanged in a different format, compared to other telemetry data, he adds.
Although scanning for Common Vulnerabilities and Exposures (CVEs) or GitHub Security Advisories (GHSA) is common practice, it can only go so far. “The more you scan, the more you find,” said Lahane. Many new vulnerabilities are found each and every day, which can lead to an inundation of false positives.
Four Pillars of Security Observability
Thus, the key to developing a more actionable security response is utilizing security scanning strategies that are more aware of the runtime context. In this context, vulnerability alerts could be prioritized, thus reducing noise. According to Lahane, four key elements make up security observability, which includes knowing…
- The attack surface
- What comes in
- What goes out
- What is changed or mutated
Understanding this sort of runtime context, along with ingress events, can be critical to spotting bad actors or plugging cloud misconfigurations.
Best Practices to Enact Security Observability
Implementing the above pillars will require a few steps. First, says Lahane, is choosing the correct tooling that enables you to exchange context throughout the development pipeline, from development to CI/CD, to production — to ensure an important feedback loop.
For example, ThreatMapper, an open-source tool maintained by Deepfence, “hunts for vulnerabilities in your production platforms, and ranks these vulnerabilities based on their risk-of-exploit.” Such a tool could be used as part of a CI/CD process to scan container workloads or Kubernetes clusters and prioritize issues that pose the most significant risk.
As I’ve covered recently, DevSecOps is critical to a successful cybersecurity strategy. The practice aims to shift security left in the development cycle to prevent flaws early on. However, “shift left, secure right” is only possible if an organization can effectively exchange context, says Lahane.
Final Thoughts
Thousands of security hits don’t easily equate to actionable observability in a security context. Instead, engineers require fewer alerts (and more contextually aware alerts) to truly benefit their cybersecurity efforts. “You need fuller security observability throughout the lifecycle,” said Lahane.
Regarding the persons actually interfacing with security observability, Lahane sees a broad spectrum of IT participating. From developers to DevOps, to CloudOps, and DevSecOps, security observability should enable a continual feedback loop throughout a business. In that vein, open collaboration is critical to ensure organizations are not scrambling upon every zero-day exposure.
We know that software supply chain exploits present a major risk and will continue to rise. But what it comes down to, says Lahane, is that the industry is missing the measurability to determine if a platform is actually vulnerable or not. “The time is nigh for open platforms,” said Lahane. “I will not be surprised if we soon see a line item of security observability on every CISO’s budget.”
Want more cybersecurity insights? Visit the Cybersecurity channel:
