I have been a part of thousands of security sales conversations over the years, and whether it be with professional security organizations such as MSSPs and MDR providers, small, medium or large enterprises, or security analysts, researchers, and thought leaders, the result tends to be the same. I see bodies strewn across the battlefield of the security sales landscape as BDRs, SEs, and experienced Account Executives get taken out by snipers from these organizations who have taken the high ground and are willing to die on one of three particular hills. However, a hill has two sides, you can climb up victoriously coming from both angles but you can simultaneously fall perilously down either side too!

The first of these hills is the agent vs. agentless debate. As security software providers get more innovative and creative with the ways in which they can interact with your environments, applications and data to keep you safe, marketers have taken these approaches and created philosophical and ideological camps around the fact that these new agentless ways of scanning and protecting an environment are the only proper way to secure a "modern" enterprise. When in reality, both agent and agentless technologies are needed for a more comprehensive approach to security. The second infamous hill is secure left vs secure right. Once again, marketers have extended a security best practice into an absolute truth. Securing left vs right refers to where security professionals should focus their security policies, controls, and resources, prior to deploying software in production or as it is running in production. I believe this is a false dichotomy and if you're only doing one side or the other than you will fall into the trap of securing left but never truly securing right (pun intended!).

The last hill where I see bodies littered in security is in the dichotomy between whether security is a people/operations problem or a security tooling/visibility/detection problem. There are those that sell and profess security is merely a bodies problem and if we had enough trained resources then we would never be hacked because we would have enough counter-hackers to fight the threat actors. Then there are those that sell the latest, greatest snake oil and band-aid to the en vogue security problem of the day; this is how enterprises end up with 75 tools in their security portfolio that are halfway implemented or are implemented but just giving the organization a plethora of in-actionable alerts to combat with their lack of skilled resources. In reality, technology is a cornerstone of any positive detection program but that technology has to help you solve both the technical security problems but the operational ones as well. In this post, I will explore the pros and cons of both sides of these various hills that have become battlefield landscapes in the security sales space. I will then explore the more nuanced, humble, and comprehensive approach that is needed as we approach each of the underlying problems that these hills grew around.

Agents vs Agentless: How Should We Instrument Security Tooling?

If you look at the Google search results for agent vs agentless, you will see the results littered with thought pieces, analyst research, and ads arguing for certain approaches over another or ads pointing you to products using that "feature" as a unique selling proposition. For those new to the space, an agent-based security is an approach in which agent code is deployed directly to a cloud, container, virtual machine, or bare-metal server to capture deep telemetry about the security of an environment and its workloads. An agentless approach is an approach in which no code is deployed on the workloads to capture information about the security of an environment and its workloads. Instead, telemetry is gathered using non-invasive methods, such as through cloud APIs or through processing log files.

The Deepfence does a good job in their blog post on the subject of agent vs. agentless highlighting some of the key differences between the two approaches in the following table:

As you can see from this chart, the discussion around how you should instrument security tooling is not black and white but shades of Deepfence blue and grey haha! It is use case and environment dependent and comes with different risks, benefits and trade-offs! For point-in-time looks at my security risk posture, for compliance and vulnerability scanning, and for public cloud posture assessments, agentless scanning is ideal as it is lightweight, is able to account for the elastic and ephemeral natures of cloud deployments, and able to use the data from the cloud providers themselves to make generalized assessments of the compliance and security of the cloud itself and how you have configured it. This is an important step in combatting our half of the shared responsibility model in the cloud but to say it is all we need is a misnomer.

There are then certain use cases, such as runtime protection, compliance controls in non-cloud environments, and endpoint protection where an agent is simply needed due to the hooks required to instrument an appropriate security policy or enact remediation on the host. The ability to see encrypted and unencrypted traffic is one of these use cases. Ransomware defense is another. Therefore, it is important to have agent and agentless security technology in your environment instrumented based on which use cases you are trying to solve, your data classification and protection schemas, and the environments you are operating in. It will end up being the case that the most strategic teams choose to eliminate risk vis-a-vis a balanced approach that combines both the agentless scanning to address vulnerability and compliance issues of their cloud environments and the agent-based capabilities in order to perform runtime protection in those environments and get deeper visibility into the application stacks deployed within the clouds. Ignoring either of these risk vectors within the environment will ultimately lead to the organization being susceptible to attackers who can effectively take advantage of the areas where the risk posture of an environment may have been understood but because the attack paths to those vulnerabilities weren't, creating runtime security incidents for enterprises to deal with.

Myself and the Deepfence team like referring to this as the ability to secure across SPACE within your environment. While the platform elements can often be secured using agentless technologies, security practitioners still need to be able to reach deep into the workload level to detect and protect against the most modern TTPs in the MITRE ATT&CK framework.

Securing Left is Cool but Have you Truly Secured Right?

If you are an IT professional you are well familiarized with the DevOps lifecycle and the perfect balance between development and operations that DevOps teams were supposed to create. Then you add security into the mix, call it DevSecOps, and this 3-team balance of magical harmony is supposed to come into existence. As we all know though, this is is far from the truth. The operational realities of DevOps and AppSec teams are not well aligned and there is constant tension before all of the automation development teams build into scalable software and the realities of that software running in production for application security teams. And neither side is to blame as they are both attempting to accomplish their individual and team responsibilities.

While the shift and secure-left camp is confident that they can automate the process of scanning and delivering code to production within the CI/CD process, ensuring that code without vulnerabilities is never shipped and deliver this promise with good intentions, there are inevitably limitations to what this approach can accomplish. Ultimately, it becomes unrealistic that all vulnerabilities can be patched prior to deploying to production due to resource constraints. 3rd party resources and components that are part of the application stack may not be subject to 3rd party and resources. Unknown vulnerabilities may be discovered after a component is deployed in production, especially given the high percentage of application stacks that use open source components in their applications.

So what do we do? Abandon all hope and never shift left or scan pre-production code for vulnerabilities? No, of course not! However, the vulnerability scanning technology set is commoditized and we should open it up to all! We can also do our best to marry the intelligence we gather from vulnerability scans about our risk posture with runtime intelligence concerning our application architecture to paint a more cohesive picture for businesses of their most vulnerable attack paths; we can then use this runtime context to more effectively correlate alerts concerning indicators of attack and compromise and respond to these correlated alerts with cloud native protection and response features. This prioritization of threats not only by severity and CVSS but by exploitability in the attack lifecycle can then help DevOps teams decide where to focus their limited resource sets, ensuring maximum risk coverage for the business by impact to the bottom line of protecting sensitive data.

This is what Deepfence refers to as securing across TIME within your security program.

Deepfence has solutions for this cohesive approach by combining its ThreatMapper (open source) and ThreatStryker (enterprise) products. This combination helps bridge the operational gap and tension DevSecOps feels today and it makes me excited to continue to build solutions for those teams. I want to ensure that development teams can effectively ship secure code to production and application teams can make secure and compliant those workloads in production! These types of comprehensive security approaches ensure that throughout the lifecycle of that asset being managed by DevSecOps, we are able to provide the appropriate security checks and protections when necessary to combat the necessary threats!

Do we have a People Problem, Technology Problem, or Both?!

If you are in the security space, you are no stranger to the endless articles about a subject matter expert problem and the hiring crunch facing companies as they try to staff and fill security and cloud roles. This Forbes article is only the latest instantiation of this fact: 45% of companies are facing a shortage of security professionals. Combine this with staffing challenges in other highly knowledge skilled roles in cloud and DevOps and companies are really hurting when it comes to having enough skilled talent in critical areas to ensure their company isn't vulnerable to attack from threat actors. This has very real consequences on an organization's ability to protect their most valuable assets and data. Many companies think that if they just were able to hire a full security team, then they would be safe from threat and attack. Many managed security providers have built out large business units or standalone MSSP practices around convincing companies that they have the bodies and it's merely handing over your mess for less. However, is it truly the case that if we just had enough trained professionals then we would be able to combat every threat? The answer is no because of the asymmetrical nature of the cat and mouse game that threat actors and defenders play. There are also an infinite number of external reasons (3rd parties, open source toolsets, SaaS software the company uses, etc.) that could introduce risk into your environment in a way where people alone could act as an effective deterrent.

On the other end of the spectrum, you have the SaaS security providers and the enterprise software providers before them who have over the years convinced security teams that they have the perfect hammer for the latest nail that's popped out of place in the risk environment. When we housed most of our applications on-prem, it was all about building defense-in-depth, a term coined by Cisco because they had all the "layers" of depth that one needed as individual product lines they could sell you. Firewalls, WAFs, EDR, etc. In today's modern environment of SaaS software, bring your own device, and remote work, CASB and next-gen EDR have been the force de majuere. But the reality is enterprises have 45 security tools on average they have deployed and there is an inverse correlation between the number of tools deployed and the ability to detect and respond to threats. This is partly because there is not enough appropriately skilled talent to configure these systems but also because that many tools without a comprehensive security framework or program leads to alert fatigue. There is no denying that these tools have value in solving specific use cases within each environment but until companies learn how to operationalize these tools towards an outcome, it'll remain a bunch of noise.

Like the other scenarios and hills we have examined in this post, the reality is much more nuanced. Companies should evaluate and purchase the necessary tools based on the use cases they need to solve and the environments they are in. However, they need to focus on tools that can better help them prioritize the focus of the limited security professionals they do have on staff and better enable those professionals to focus on higher orders of activity to keep enterprises safe. Deepfence achieves this by not only consolidating several critical security toolings into one platform (cloud workload protection, cloud native application protection, runtime protection, vulnerability management, detection and response) but it gives security professionals the ability to see both the attack surface (i.e. what you're protecting and it's vulnerabilities) with the attack paths (i.e. how a threat actor can achieve exploiting that vulnerability through different MITRE TTPs). This helps prioritize where risk is not only present, but exploitable and helps an enterprise direct their limited resources to lay down protection against the most exploitable attack paths first and then focus on hardening the rest of the environment. Technology and the professionals it supports should have a symbiotic relationship with each other and not an antagonistic one where there is fear or anger about displacement or automation.

Don't Die Unnecessarily in Security Sales

As security professionals, we need to be less dogmatic in which ideologies we cling onto. There is so much nuance and complexity in our space, that black and white views only serve to divide and exclude important viewpoints, technologies, and practices that can be beneficial to security our most sensitive data and applications. There is no room, in my opinion, for an "I'm smarter than you" attitude because I believe in one detection technique versus another. Likewise, I believe security sellers need to do a better job of explaining the nuances in their technology and the use cases they solve and do a better job acknowledging the operational realities of the individuals they are selling software to. They need to understand the spectrum of the 3 problems I have described above and be able to speak confidently to how their technology will work hand in hand with the operators of the business to stop specific attacks in their tracks. I feel as if both sides of this equation showing a little empathy will allow the industry to better rise up and tackle our industry's most pressing problems more effectively and with a great support network at our backs.

If you'd like to learn more about how Deepfence approaches each of the three problems above and can be your security partner for a better future, reach out and have a conversation. Or share your experiences with these three challenges, other challenges you experience, or your perspective on these three issues by commenting below!