Menu of cybersecurity risk management options

A simple visualization of risk management options, explained in the context of cybersecurity but broadly applicable.

Avoidance

Eliminate at-risk components entirely—ideal when practical, though it rarely is.

A common example is credit card processing. Many organizations choose not to store or process credit card data, instead using third-party gateways. This avoids the risks, costs, and compliance burdens (e.g., PCI DSS) of handling sensitive card information internally.

Mitigation

Manage risk exposure or impact using preventive, detective, or response controls—the most common cybersecurity approach.

Most cybersecurity products and services focus on mitigation. Endpoint detection and response (EDR), identity security solutions (IdPs), cloud security, security event management platforms (data lakes, SIEM), and managed security services (MSSP, MDR) all help mitigate present and emerging risks.

Transference

Find someone else to actively manage the risk. You still have a risk, and transference is rarely wholesale, so a good understanding of your remaining risk is critical.

“Risk transference” used to be largely synonymous with “insurance.” Today, using cloud-based applications or infrastructure is one of the most common forms of cybersecurity risk transference. Availability, integrity, product security and more are shared with the vendor, allowing the customer to build upon a strong foundation. That said, widespread adoption of these technologies has also created a tremendous concentration of trust, which can have a disastrous impact if and when adversaries compromise cloud vendors.

Acceptance

Evaluate the potential cost of a realized risk. If prevention or mitigation costs aren’t justified, explicitly accept the risk and plan accordingly. Often the least desirable option for security practitioners—though business leaders may be more willing.

A typical scenario involves legacy or niche applications running despite known vulnerabilities, risk of failure, or other scenarios. When mitigating or replacing such systems is too costly, risks are accepted, often supplemented by basic mitigations like isolation or enhanced disaster recovery planning.

The more labels you have for yourself, the dumber they make you. Permalink

One of Paul Graham’s best.

If people can’t think clearly about anything that has become part of their identity, then all other things being equal, the best plan is to let as few things into your identity as possible.

Most people reading this will already be fairly tolerant. But there is a step beyond thinking of yourself as x but tolerating y: not even to consider yourself an x. The more labels you have for yourself, the dumber they make you.

Defining security outcomes

I’ve long viewed incidents as one of an organization’s very best tools for measuring everything from cybersecurity effectiveness, to overall operational maturity. Unsurprisingly, I’d also recommend using incidents to define and understand security outcomes (i.e., whether your costly security-related investments are getting the job done).

Here are three relatively simply incident-centric cybersecurity outcomes to consider:

• The one security outcome to rule them all is the material cybersecurity incident. Although this term was popularized by the U.S. Securities and Exchange Commission, every organization—regulated or not—defines “materiality” for itself. This creates a neat, tidy, binary condition: either you have had a material cybersecurity incident or you have not.

• Beyond material incidents, incidents at-large can be categorized using organization-specific definitions or common severity, or SEV levels (e.g., SEV-1 being most severe, and SEV-2+ being increasingly less so). Using a standard SEV model, some SEV-1 incidents will be material, and all material incidents will be classified as SEV-1.

• A third outcome is cost per incident, which encompasses the expenses of technical controls, personnel, and external partners. Typically, lower-severity incidents incur lower costs, while costs rise exponentially with severity.

It’ll be easiest to implement these starting with the first: define what would constitute a material cybersecurity incident for your organization. Don’t overthink it. If it prevents you from making money, serving your customers, or both then that may be a good enough start. Once you’ve defined that and believe you’d know materiality when you see it, move on to defining incident severity level and performing basic incident management, and then evolve your incident management process to include cost.