Dispelling Continuous Threat Exposure Management (CTEM) Myths
Posted by: Chris Peltz
Gartner defines Continuous Threat Exposure Management (CTEM) as a set of processes and capabilities that enable organizations to continually and consistently evaluate the accessibility, exposure and exploitability of their digital and physical assets. Though CTEM is a very new approach, there is already an abundance of myths and misconceptions.
Myth 1: CTEM is a technology space.
Quite a few vendors have grabbed onto the CTEM moniker in their marketing—and for good reason. Continuous Threat Exposure Management is a compelling and progressive strategy that helps us derive better value from Security technology. However, it’s very important to note that CTEM is a best practice approach (like Zero Trust) and not a technology. In fact, there are no singular vendor technologies on the market today that allow for full CTEM operationalization. CTEM requires the coordination of a collection of security tools to be effective.
Myth 2: CTEM is the new name for Vulnerability Management.
Gartner does predict that most enterprises will replace legacy Vulnerability Management (VM) programs with CTEM-like programs over the next five years, but that is certainly not to say that CTEM is a new branding for legacy VM. CTEM was developed in part to address issues organizations have consistently experienced with properly driving down risk with traditional Vulnerability Management programs. When comparing CTEM and traditional VM, there are important differences in scope and a uniquely different overall paradigm. We’ll expand on these differences in future CTEM articles in this series.
Myth 3: I need to invest in technology or personnel to adopt CTEM.
Just as there is no one “CTEM platform,” there is not always a need to make major technology investments when embarking on a CTEM adoption journey. The very first stage of CTEM is Scoping, in which we realign our find-and-fix security operations with critical business functions. This scoping exercise is entirely human-driven and requires no technology adoption. We find that most customers can progress quite far in CTEM adoption simply by reorienting their existing toolsets before expanding to consider additional technology adoption.
The same principle applies on the personnel front—the initial gains of CTEM adoption can be achieved by simply leveraging the current team you have today. A knowledgeable partner can be valuable in providing guidance and coaching in the adoption process, but partner consulting is more of an accelerating and enabling factor rather than a hard-and-fast requirement. The hallmarks of a CTEM-aligned practice revolve around reducing silos and fostering better collaboration on exposure reduction across functional teams.
Myth 4: We may struggle to comply with regulatory obligations if we adopt CTEM.
It is well understood that many parameters of security operations are rooted in fulfilling regulatory and/or policy obligations, which can cause reluctance to adopt new ideas out of fear that the organization may drift into a non-compliant state. When implemented dutifully, CTEM is actually an enabling strategy for better-orienting security operations to business and regulatory obligations, as the process of scoping helps exposure management personnel better understand these obligations and ensure they are fulfilled within the parameters of the given scope. Scoping is a powerful opportunity to ask questions about obligations within a confined context that allows for a better chance of adhering to those parameters and being able to report accurately on that adherence.
Also, CTEM is a functional security strategy and is not mutually exclusive to other best practice frameworks your organization may subscribe to, such as the NIST CSF or CIS benchmarking.
Myth 5: CTEM isn‘t feasible in a decentralized organization.
One of the most frequent myths we hear is that CTEM isn’t logistically viable in a siloed organization that has autonomous business units or member organizations. Luckily this isn’t the case, we see some of the most successful early adopters of CTEM being organizations that have these decentralized structures. The reason CTEM can accommodate a decentralized organization better than legacy Security functions is that the scope-centric nature of CTEM can be applied to the various business units/member organizations.
Myth 6: CTEM is a big adjustment, and we aren’t ready for a cut-over.
Another major myth holding back candidate organizations from embracing CTEM is the idea that existing Security programs need to be discarded and the organization will experience a binary switch-over. Because CTEM implementation centers around onboarding one or a few scopes at a time, it can be gradually implemented over the course of months or even years without disrupting legacy operations. Even a preexisting relationship with a managed service provider doesn’t have to inhibit CTEM adoption; CTEM can be used to reframe the service partnership in a more mutually beneficial risk reduction context.
Myth 7: The CTEM framework doesn’t properly align with the reality of our business.
The core concepts of CTEM are what offer the most benefit, there is no true criteria at this time for executing CTEM “by the book”. As long as the Exposure Management program you are developing is true to the core concepts of business alignment, breadth of discovery, focus on information reliability, and commitment to partnering with stakeholders for exposure reduction, you can feel free to adjust specific elements to your needs. The reason CTEM was developed was to help address practical issues with find-and-fix security, so it’s important our CTEM-based programs are viable within the context of our organizations and actualize the improvements they were designed to provide.
As Security professionals we shouldn’t let misconceptions or misrepresentations surrounding CTEM deter us from actively striving to incorporate Exposure Management best practices into our operations.
Chris Peltz
Practice Lead, Northeast Region,
GuidePoint Security
Chris Peltz has a technology career spanning over fifteen years with experience in industries including financial services, higher education, software development, and healthcare. Currently he contributes to the Engineering leadership in the Northeast at GuidePoint Security. His focus is on partnering with organizations of varying sizes and industries to design, implement, and maintain results-based functional security programs.