There are numerous security solutions on the market today that promise some form of “continuous” security. While this is certainly not an exhaustive list, the ones immediately come to mind are:

  • Continuous Asset Management
  • Continuous Security Validation
  • ctem" class="keyword-link">Continuous Threat Exposure Management
  • Continuous Application Security Monitoring
  • And of course… Continuous Penetration Testing

What we frequently lose sight of is that what all these solutions are really offering is information related to their specific domain expertise. While information is easy to produce on a continuous basis, it is imperative that this information be properly utilized to have the most effective impact on your security posture. In our case, Sprocket provides information related to the validity of attack paths for your organization. Since a single valid attack path often identifies gaps in multiple layers of security controls, it is essential that all related people, processes, and technologies, be considered in your remediation efforts.

Advances in Technology ≠ Our Advances in Security

We tend to focus too heavily on the technology solutions alone. While technology has advanced considerably over the years to provide the above-mentioned continuous services, we are still struggling with the same ongoing problems. For example, in 2008 the Consensus Audit Guidelines were published by SANS. These were referred to as “Attack-Based Metrics” and identified the controls that would allow organizations to either prevent, detect, or quickly recover from known attacks. The first two controls were:

  1. “Inventory of Authorized and Unauthorized Hardware”
  2. “Inventory of Authorized and Unauthorized Software”

Today we know this framework as the CIS Critical Security Controls for Effective Cyber Defense and, except for some minor wording changes, the first two controls have remained unchanged. It is also worth noting that these controls are identified in order of priority; meaning that controls one and two are the most important first steps of your security program.

After 16 years (of this writing) of access to a framework, that provides direct mappings to other commonly deployed frameworks and regulations, our team of pentesters regularly identifies attack paths through assets or software that were previously unknown to the organization.

How can this be? How, after 16 years, have we been unable to achieve the two most important first steps of a security program, especially with all of these “continuous” technology solutions at our disposal?

Are we focusing on the wrong things?

Security is a Continuous Process, not an Achievable State

You may be able to achieve security from a particular threat-actor over a particular threat-vector at a particular point-in-time, but without ongoing processes that are continuously being updated with current, relevant, information, that moment will be fleeting.

Traditional point-in-time pentesting is a classic example of this and resembles the following.

  • A pentest occurs
  • Findings are reported, prioritized, remediated, or accepted
  • Retesting of those specific findings occurs
  • Report is updated
  • The organization is “secure”

This process repeats annually and typically resembles a game of whack-a-mole as organizations smash the individual findings as they arise. What is lacking in this process is a continuous and holistic security mindset; a mindset that would tell us that the recurrence of similar findings is an indicator of a larger systemic problem.

What If We Changed Our Focus?

What if instead of playing pentest whack-a-mole, we used the results to refine our operational security controls to address the underlying root cause of findings? Let us analyze the following scenario.

  1. A pentester gains an initial foothold through an undocumented asset
  2. Moves laterally to a misconfigured host and gains user-level permissions
  3. Takes advantage of a locally installed admin tool to identify locations where domain admins are logged in
  4. Exploits an outdated service with an unpatched vulnerability
  5. Extracts domain admin credentials from memory
  6. Creates a persistent Domain Admin account in Active Directory

In this scenario, it is easy to identify and address some of the immediate problems, and in the case of #1 and #2, that should be the priority. After that, however, we need to start asking some additional questions, to get to the root cause.

  1. Why was this asset undocumented? Who owns this asset? What process failed?
  2. What was the misconfiguration? Why was it misconfigured? Was a configuration baseline followed? Was an unauthorized change made in production?
  3. Why does a regular user have access to locally installed admin tools? Is least privilege being followed?
  4. Why was there an unpatched exploitable vulnerability on a system used by a domain admin? Is this application in the software inventory? Is it part of the patch management process?
  5. Why were passwords extractable from memory? Was a configuration baseline followed? Does the baseline define settings for WDigest, LSA protection, restricted admin mode, debugger user rights, etc.?
  6. Was the creation of a new DA account logged? Was it alerted? Did anyone see/respond to the alert?

Do you see the differences here? It is not about simply identifying, exploiting, and then patching a CVE. It is about taking the underlying context and lessons learned to provide input into your broader security program. Since your security program, as a whole, is a collection of people, processes, and technologies it is important to ensure that all these components are aligned on remediation as well as future prevention, detection, and response of the same or similar attack paths.

Final Thoughts

As much as we like shiny new security tools with blinking lights, security is more about operational processes than it is technology solutions. Your technology solutions should feed into your operations and either answer or prompt the necessary questions for you to further refine and improve the continuous human-driven processes that allow you to effectively prevent, detect and respond to incidents. This, and only this, is how you achieve an effective continuous security mindset across your organization.