A technology adoption model for cybersecurity teams

6 minute read

This article is adapted from a presentation (charts + talk track) I’ve maintained over the years as a tool to help myself and others understand how technology adoption drives the work we do in cybersecurity, and where we are in the technology adoption cycle at any given time. Charts revised late 2023.

Cybersecurity isn’t an isolated problem space. Cybersecurity as a discipline exists to safeguard data, typically by securing the underlying technologies used to access it. And because adoption of new technologies will always outpace our ability to secure them to the degree we’d like, cybersecurity is an inherently unsolvable and cyclical problem space.

This is one reason I enjoy studying cybersecurity and risk management maturity models. “Better at security today than we were yesterday” is an admirable mantra for any cybersecurity team. However, one thing I’ve learned about this type of modeling is that it helps us understand and improve upon the work, but typically doesn’t help us understand the inputs—technologies adopted by the business and users—that ultimately drive it.

Technology adoption cycle overview

This model focuses instead on where a given technology is on its journey from initial availability through to the low-level understanding required to effectively secure it. The primary use case is planning and alignment within a given organization, based on the technology stack and security controls at a point in time. By plotting key technologies relative to one another and along a continuum, it can be easier to track progress, maturity, depth of understanding, and more.

Availability

First, technology becomes available to users. The major mobile app stores alone publish somewhere north of 1,000 new applications daily, and this is to say nothing of websites, SaaS applications, and other services beyond the mobile ecosystem. The proliferation of new software in particular is staggering, and generative artificial intelligence (GenAI) is driving the cost and time required to launch new applications and services down by the day.

Here it’s also worth noting that most cybersecurity practitioners are employed to protect businesses, but there’s no meaningful or predictable delineation between “business” and “consumer” technology. The prevalence of “bring your own device” (BYOD) is a clear indicator of this phenomenon, as are the countless businesses that leverage social media platforms, individuals who keep personal appointments on their work calendar, and more.

Adoption

Naturally, users start to adopt these new technologies. And not always because they should, but because they can.

The launch of the first iPhone is the canonical example of this phenomenon: Overnight, seemingly everyone had an iPhone. And while enterprises could ignore some noisy software engineers clamoring for access to corporate email and productivity apps on their new iPhones, they couldn’t ignore the CEO.

Adoption happens, and because it’s largely a function of availabilty coupled with consumer or user demand, if often occurs without the broader technology and/or security team’s awareness.

Management

Largely in response to adoption, enterprises make some attempt to manage technology. That is, to get a handle on who’s using it, how, and for what. Early “management” may be little more than a crude accounting of who’s using the tech, and an attempt to control the blast radius should something go wrong.

Early attempts to manage a new piece of technology will usually focus on the “bookends”: How the software is accessed (e.g., via identity and access management), and how the software is managed (e.g., whether it can be installed, or by removing it if unauthorized). For a piece of technology with sufficient access to sensitive data, these are imperfect but important first steps towards management.

Understanding

Once we dedicate resources to managing a given technology, our understanding of the technology improves, out of some mix of necessity and curiosity. This is where a lot of wildly valuable automation, control, and security tools (often free and/or open source) begin to materialize.

Many of the leading solutions in the device management, monitoring, and myriad other spaces were born during this evolution from basic management of an emerging technology to a better, deeper, and more meaningful understanding of how it’s being used, what it’s accessing and how, and ultimately how it can be better monitored and/or controlled.

Security

We can’t secure what we don’t understand.

Only once a technology becomes well understood will enterprises and controls mature to effectively secure it. This is where hackers and the cybersecurity community shine. Taking a technology from “we can keep a lid on it” to “we know more about this than the people who made it” is a hallmark of hacker culture and the cybersecurity industry that often pays its bills.

We’re still not “done”, but technology that reaches this phase is generally well studied and a robust set of controls are available. It also stands to reason that these technologies also have a well developed threat model and may be frequently targeted by adversaries, who are naturally interested in widely adopted, entrenched technologies.

An illustrative look

Plotting the modern tech stack

Here’s a illustration of what this looks like in practice, using a common set of technologies:

In general, technologies farthest to the “left” will be characterized by one or more of the following:

• The inner workings of these technologies aren’t well understood and/or documented
• Threat models are not widely understood or accepted
• Observability may be lacking (i.e., APIs or other means of accessing access, usage, and security event data aren’t robust, and sometimes do not exist at all)
• Lack of robust built-in or third-party security controls

Grouping technologies by family or type

This same phenomenon also applies to types of technology. In fact, determining whether we’re dealing with an evolutionary (e.g., our 1,001st project management tool) or revolutionary (e.g., ChatGPT) technology is how we spot a leading indicator that we’ll have a lot of net new work to do.

As you reflect on the above illustrations, note a few things:

• It took us decades to do a passable job of securing the “traditional” technologies on this chart (Windows, macOS, and Linux).
• In less than one decade, most everything else on this chart was introduced, and each time the cycle began anew.
• In a single year (2023), the widespread adoption of GenAI put that technology on the fast track through this cycle, but also had the rare side-effect of causing us to reevaluate most existing technologies, as GenAI was adopted by end users and much of our existing technology stack simultaneously

Takeaway: Technology adoption will always outpace security

The takeaway here is not how we adopt technology, but that technology adoption will always outpace security, and this is best thought of as a primitive and not a failure.

For every technology that progresses through this cycle, expect countless new inputs. And expect that a problem that we’ve solved for in the context of a particular technology or domain will need to be revisited and implemented in new ways, either because technology or assumptions change, but also because we work in an adversarial industry, and the enemy never rests.

Using this model

Hopefully this model is useful, irrespective of where you are in your cybersecurity journey.

For those looking to enter the field, it may help you understand what to expect.

For those actively involved in cybersecurity, either as dedicated professionals or as one of the millions of technologies for whom cybersecurity is “other duties as assigned”, it can be a useful framework for visualizing and/or forecasting technologies that impact your work.

And in general, it highlights the single biggest externality affecting our profession. Understanding that this is how it works may help you avoid some of the burnout and nihilism that plagues our industry, as many practitioners strive for “perfect” or “done”, rather than striving for balance given that the cycle is supposed to continue.

The End of Software (essay by Chris Paik) Permalink

1 minute read

An interesting essay and take by Chris Paik (Twitter):

Software is expensive because developers are expensive. They are skilled translators–they translate human language into computer language and vice-versa. LLMs have proven themselves to be remarkably efficient at this and will drive the cost of creating software to zero. What happens when software no longer has to make money? We will experience a Cambrian explosion of software, the same way we did with content.

Vogue wasn’t replaced by another fashion media company, it was replaced by 10,000 influencers. Salesforce will not be replaced by another monolithic CRM. It will be replaced by a constellation of things that dynamically serve the same intent and pain points. Software companies will be replaced the same way media companies were, giving rise to a new set of platforms that control distribution.

SaaS, ARR, magic numbers–these are all shorthand to understand the old model of business building in software, one where the expense associated with creating software was a moat. The invisible hand has been stayed in software for a long time, but LLMs will usher in its swift, familiar corrective force. Majoring in computer science today will be like majoring in journalism in the late 90’s.

Almost as interesting as the essay is the closest thing Paik’s firm has to a blog, which is yet another Google Doc.

Respect the simplicity.

Search or subscribe to SEC 8-K Material Cybersecurity Incident filings

1 minute read

In 2023, the Securities and Exchange Commission (SEC) published rule 33-11216 Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure, where the operative requirement is that companies disclose material cybersecurity incidents. The summary disclosure requirement is as follows:

Form 8-K Item 1.05 - Material Cybersecurity Incidents

Registrants must disclose any cybersecurity incident they experience that is determined to be material, and describe the material aspects of its:

• Nature, scope, and timing; and
• Impact or reasonably likely impact.

An Item 1.05 Form 8-K must be filed within four business days of determining an incident was material. A registrant may delay filing as described below, if the United States Attorney General (“Attorney General”) determines immediate disclosure would pose a substantial risk to national security or public safety.

Registrants must amend a prior Item 1.05 Form 8-K to disclose any information called for in Item 1.05(a) that was not determined or was unavailable at the time of the initial Form 8-K filing.

How to find or subscribe to SEC cybersecurity incident disclosures

In theory, looking for Form 8-K that contains Item 1.05 should be sufficient. However, there are a number of disclosures that contain other Item types and references. For instance, this Okta filing simply references both their standard quarterly earnings press release and a blog post, both published on the same date, disclosing a security incident.

Here are a few ways to find and/or subscribe to relevant filings using SEC-provided tools.

Historical EDGAR Header Search (deprecated, but available as of 2024-05)

Search for initial disclosures

RSS feed of initial disclosures

EDGAR Full Text Search

Search for initial disclosures

Search for all 8-K filings related to cybersecurity incidents

By way of example, the RSS feed returned by the Historical EDGAR Header Search will give Feedly users a neat and tidy list of disclosures that looks like this:

The Cybersecurity Maturity Matrix

1 minute read

I was introduced to the Cyber Defense Matrix circa 2015, shortly after it was released by Sounil Yu. The framework is based on two dimensions: Asset classes, or things you want to defend. And the NIST Five Functions, activities performed to defend assets, which range from identification through post-incident recovery.

I’ve always found this framework simple, adaptable, and useful for a wide variety of purposes:

• As a organizational security leader, to catalog the organization’s cyber and information security controls
• As a vendor, to map customers’ capabilities, and to illustrate where and how our own security solutions contribute to their program
• As a security product leader, to visualize our current strengths, and to chart a path into new areas

No matter the use case, it’s an invaluable tool for discussion and alignment related to security controls, operations, maturity, products, and more. And for all of the times I’ve found myself remaking this matrix on mediums ranging from slide decks to paper flip charts, I’ve always wanted a tool to make it easier to get started, and easier to save our work.

The Cybersecurity Maturity Matrix is a simple tool for visualizing maturity, control coverage, and other aspects of your security program. It’s based on the Cyber Defense Matrix, and provides the following features:

• Customizable asset classes: Start with the default set, or the original Cyber Defense Matrix asset classes, and then make any changes that you wish.
• Four maturity levels: Each cell can be left empty or assigned one of three states:
• Optional cell annotations: Use annotations to list products, responsible individuals or teams, or dates when you expect to reach a milestone.
• Export to PNG: Drop the completed matrix into your doc or presentation in seconds.
• JSON export and import: Export the details of your completed matrix to JSON, so that you can import and update it whenever you wish.

Try it now: https://cybermaturitymatrix.com

Something else you’d like to see? Drop me a line: cmm-feedback @ this domain.

Trust and the cybersecurity buyer’s journey

2 minute read

The buyer’s journey is a common framework for understanding how customers (who have problems) find products provided by vendors (to address problems).

• Awareness - Knowing that a problem and potential solutions exist. Brand awareness is a key component of this stage.
• Consideration - Which potential solutions are you considering?
• Evaluation - Of the solutions being considered, how do they stack up? Feature comparisons, pros and cons, and other criteria are examined.
• Purchase - A solution is chosen and purchased. This stage is also referred to as “Adopted.”
• Post-Purchase - The solution is implemented. Critically, it’s here that the customer makes some early and important determinations with regards to how the solution performs relative to their expectations and the vendor’s promises during Evaluation.

What’s unique about the security industry?

Put simply: The security industry is grounded in the principle of trust:

• Trust that the team has a deep understanding of the problem, credibility in the space, and acts with integrity.

When companies purchase virtually any other type of technology, they tend to seek out specific functionality, can easily determine whether the product works as intended, and may have an interest in the roadmap but aren’t dependent on future functionality for their success.

When we purchase security products—particularly those that we rely on to perform critical operational functions—our journey is unique:

• We want some specific functionality (e.g., reporting, interoperability), but what we really want is an outcome (e.g., a net reduction in harmful emails delivered to users).
• While we typically have some tests that we can use to validate that the system works as intended, we can be assured that the system will face an endless barrage of inputs designed by a capable actor to avoid detection.
• We often have a keen interest in the vision and roadmap as a bellwether for the team’s depth of understanding, commitment, and ability to productize or operationalize threat intelligence findings (i.e., as adversaries evolve, will the product evolve to meet them, and do so in a timely manner?).

Major features we’ll try to discern early on by way of the website, webinars, and other public materials. Efficacy we can test superficially during an evaluation. But oftentimes we won’t get to Evaluation (or even Consideration) unless we have a good sense for whether the team understands the problem and has credibility in the space—key ingredients of trust. Most of the time, we’ll have a sense for this as (or before) we begin this journey, by virtue of personal or professional networks, conferences, and published research.

Also note that trust in the team can absolutely compensate for lack of features, or even some lack of efficacy. Cybersecurity is an adversarial discipline, and great products work a great percentage of the time, but nothing’s perfect. A trustworthy and capable team will shine in the face of failure, responding with transparency and decisive action.

This concept is important to leaders because trust, inclusive of credibility and integrity, are virtually impossible to fake or decide on a whim that you want. The behaviors and principles that lead to trust either come naturally to founders and early employees, and are integral to company culture, or they are not. And ultimately, despite how nice your product and marketing look, security practitioners are looking through these things to determine whether and to what degree they trust your team to deliver on an ongoing basis against a determined and skilled adversary.