Tag Archives: risk

Cyber Materiality Engineering: How CISOs Pre-Decide When Risk Becomes a Board Event

Posted on by
Reply

A ransomware incident does not stay technical for very long.

For about the first fifteen minutes, it may look like a security operations problem. A strange alert. A locked server. A suspicious authentication chain. A vendor portal behaving badly. A handful of systems no longer responding the way they should.

Then the blast radius starts to widen.

Operations wants to know whether they can keep running. Finance wants to know whether revenue recognition, cash movement, reserves, or forecasts are exposed. Legal wants to know whether notification clocks have started. The CEO wants to know what can be said, to whom, and when. The board wants to know whether this is “material.” Investors may eventually ask the same thing, only with less patience and more lawyers.

This is where many organizations discover that their cyber incident response plan is not really an enterprise decision plan. It tells people who to call. It tells the SOC how to preserve evidence. It may even have a communications tree and a sample press statement.

But it often does not answer the question that matters most in the first few hours:

At what point does a cyber event become a board-level business event?

That decision should not be invented under pressure.

The SEC’s public-company cybersecurity disclosure rules, adopted in 2023, require disclosure of material cybersecurity incidents and periodic disclosure about cybersecurity risk management, strategy, and governance. The SEC’s own small business compliance guide summarizes the rule as having two major components: incident disclosure and annual disclosures about cyber risk management and governance. 

That does not mean every cyber event is material. It does mean that mature organizations need a defensible way to decide, before the incident happens, how they will evaluate materiality when the facts are incomplete, emotions are high, and the clock is moving.

That is what I mean by cyber materiality engineering.

Not compliance theater. Not a prettier incident response binder. Not another “compliance is not security” lecture.

Cyber materiality engineering is the deliberate design of decision architecture around the point where cyber risk becomes enterprise risk.

A man with glasses performing an audit with careful attention to detail with an office background cinematic 8K high definition photograph

The Problem: Materiality Is Usually Decided at the Worst Possible Time

Most organizations make materiality decisions in the middle of uncertainty.

That is understandable. Incidents are messy. Early facts are often wrong. Initial impact estimates are incomplete. Forensics may lag behind business reality. Threat actors lie. Vendors understate. Internal teams overcorrect. Executives want certainty before making commitments, but certainty is usually not available when the most important decisions must be made.

The result is predictable.

The CISO is asked, “Is this bad?”

Legal asks, “Is this reportable?”

Finance asks, “How much will this cost?”

The board asks, “Why are we just now hearing about this?”

The security team may answer technically: number of systems affected, indicators of compromise, malware family, containment status, suspected access path.

Those answers matter. But they do not, by themselves, answer the enterprise question.

A materiality decision is not simply a severity rating. It is not the same thing as “critical” in the ticketing system. It is not the same thing as whether data was definitely exfiltrated. It is not even limited to direct financial loss.

A cyber incident may be material because it disrupts operations, threatens liquidity, harms customers, triggers contractual obligations, changes risk assumptions, undermines confidence in management, or creates a reasonable likelihood of financial, legal, or reputational consequences that matter to investors, members, customers, regulators, or other stakeholders.

That is why the decision cannot live inside security alone.

The CISO may own much of the evidence. The GC may own the disclosure and privilege strategy. The CFO may own the financial impact model. The CEO may own external accountability. The board owns oversight.

But the organization owns the decision.

When that decision model is vague, the organization tends to fall into one of two bad patterns.

The first is under-escalation. Everyone waits for perfect evidence. Nobody wants to alarm the board. The incident is treated as a technical matter until it suddenly becomes a legal, financial, or reputational crisis. By then, the company is explaining not only the incident, but also the delay.

The second is over-escalation without structure. Every ambiguous event becomes an executive fire drill. The board gets noise instead of judgment. Teams burn cycles producing speculative updates. Decision-makers become fatigued. Eventually, real signals are missed because everything has been treated like an emergency.

Both are governance failures.

The right answer is not “escalate everything.” The right answer is to engineer a decision system that can operate under uncertainty.

A Five-Part Cyber Materiality Model

A useful cyber materiality model should be simple enough to use during an incident and robust enough to defend after one.

I like a five-part model:

  1. Operational impact
  2. Financial exposure
  3. Customer or member harm
  4. Regulatory, legal, or contractual trigger
  5. Evidence confidence

The first four describe impact. The fifth describes how sure we are.

That distinction matters. A low-confidence, high-impact scenario may deserve board escalation even before the facts are complete. A high-confidence, low-impact event may not. A mature process separates what we know, what we suspect, what we can prove, and what could reasonably become true as the investigation unfolds.

1. Operational Impact

Start with the business.

What critical service, product, process, facility, workflow, or revenue engine is impaired?

Security teams often think in systems. Boards think in business functions. The bridge between the two is operational impact.

A domain controller outage is not material because it is a domain controller. It becomes material when it prevents loan processing, stops manufacturing, interrupts clinical operations, halts order fulfillment, delays payroll, or takes down a customer-facing platform.

The pre-incident work is to map technical dependencies to business services before the crisis.

That means knowing which systems support revenue, which systems support safety, which systems support regulated processes, which systems support customers, and which systems create cascading failure if they are unavailable.

This is where many business impact analyses fall short. They exist as disaster recovery paperwork, not as live decision tools.

For materiality engineering, the question is not merely, “What is the recovery time objective?”

The better question is:

If this function is impaired for 4, 12, 24, or 72 hours, who outside IT will care, and why?

2. Financial Exposure

Next comes financial exposure.

This includes direct loss, but it should not stop there. A real financial model should consider response costs, lost revenue, fraud losses, contractual penalties, customer credits, legal fees, regulatory exposure, insurance retention, increased borrowing pressure, delayed transactions, impairment of assets, and potential impact to forecasts.

CFOs are especially important here because security leaders may not know which financial thresholds matter inside the company.

A $500,000 incident may be noise in one organization and existential in another. A two-day outage may be tolerable in one business model and catastrophic in another. A fraud event that looks small in gross dollars may become material if it exposes a control weakness in a high-trust environment.

Pre-deciding thresholds does not mean creating a magic number where everything above it is material and everything below it is not. That is too simplistic.

It means defining ranges that guide escalation:

  • Known or estimated loss
  • Reasonable worst-case exposure
  • Confidence in the estimate
  • Impact to forecast, liquidity, covenants, or reserves
  • Whether the exposure is isolated or systemic

The number matters. The story behind the number matters more.

3. Customer, Member, or Patient Harm

Cybersecurity is often discussed as if the primary victim is the company.

Sometimes that is true. Often it is not.

Customers may lose access to services. Members may experience account fraud. Patients may experience care disruption. Employees may have sensitive personal information exposed. Business partners may inherit risk through integrations. In a SaaS environment, one tenant’s compromise may raise questions about other tenants, even when segmentation worked exactly as designed.

Customer harm is not just a public relations category. It is a materiality input.

The board does not only need to know whether data left the building. It needs to know whether stakeholders were harmed, whether they could be harmed, whether the organization can identify who was affected, and whether the organization has a credible plan to reduce further harm.

A mature materiality playbook should define harm categories in advance:

  • Loss of access
  • Loss of funds
  • Exposure of sensitive data
  • Business interruption for customers
  • Safety or health implications
  • Loss of trust in a core service
  • Downstream impact to dependent organizations

This is especially important for financial institutions, healthcare, SaaS providers, managed service providers, and any organization whose customers rely on it for critical operations.

The question is not only, “Did we get breached?”

The better question is:

Who else is now carrying risk because of what happened to us?

4. Regulatory, Legal, and Contractual Triggers

Cyber events do not happen in a vacuum.

They intersect with privacy laws, sector regulators, customer contracts, cyber insurance policies, law enforcement considerations, public disclosure obligations, banking rules, vendor commitments, litigation holds, and sometimes national security reporting expectations.

The SEC rules are one example for public companies, but they are not the only driver. The SEC final rule requires registrants to disclose material cybersecurity incidents on Form 8-K and also requires annual disclosures related to cybersecurity risk management, strategy, and governance. FINRA has also summarized the SEC rule as requiring disclosure of material cybersecurity incidents and periodic disclosure about cyber risk management, strategy, and governance. 

Private companies should still pay attention. They may not have the same public-company filing obligations, but they often face customer, lender, insurer, regulator, or board expectations that look very similar in practice.

This is where the GC’s office earns its seat in the process.

The pre-incident materiality model should identify which triggers matter by jurisdiction, industry, contract type, data type, customer segment, and regulator. It should also define who has authority to interpret those triggers during an incident.

A common failure mode is to treat regulatory analysis as something that begins only after forensics has reached a conclusion.

That is too late.

Legal analysis should start when facts suggest a reasonable possibility that a trigger may exist. That does not mean making premature disclosures. It means preserving options, protecting privilege where appropriate, collecting the right evidence, and preventing casual internal statements from becoming tomorrow’s exhibit.

5. Evidence Confidence

Finally, and most importantly, the model must account for confidence.

This is the part many materiality discussions miss.

Early incident facts are probabilistic. We may know that an account was compromised, but not whether data was accessed. We may know that ransomware executed, but not whether backups are clean. We may know that a vendor was breached, but not whether our environment or data was touched. We may know that a model ingested sensitive data, but not whether that data was retained, exposed, or used inappropriately.

A decision model that requires certainty will fail.

Instead, materiality engineering should define evidence confidence levels:

  • Confirmed: supported by logs, forensic evidence, business records, or direct observation.
  • Probable: strongly indicated by multiple credible signals, but not fully proven.
  • Plausible: possible based on known facts, threat behavior, or exposure path.
  • Speculative: not supported yet, but raised as a scenario to monitor.

This allows the organization to say something much more useful than “we do not know yet.”

It can say:

“We have a plausible but unconfirmed path to customer data exposure. Operational impact is low. Regulatory impact may be high if confirmed. Confidence is currently moderate on access and low on exfiltration. We recommend escalating to the disclosure committee and briefing the board risk chair within the next update cycle.”

That is governance.

Implementation: Build the Decision Tree Before the Incident

A materiality model is only useful if it becomes operational.

That means building a pre-incident decision tree that connects facts to actions.

The decision tree should not try to predict every scenario. It should define how the organization moves from signal to severity, from severity to escalation, and from escalation to board-level decision.

At a minimum, it should answer these questions:

Who can convene the materiality group?
This should not require a committee meeting to schedule a committee meeting. The CISO, GC, CFO, CEO, or incident commander should have clear authority to trigger the process.

Who is in the materiality group?
Typically: CISO, GC, CFO, CIO or CTO, privacy leader, communications, business owner, risk leader, and incident commander. For some organizations, internal audit, compliance, investor relations, HR, or vendor management may also be necessary.

Who makes the recommendation?
The group should produce a recommendation, but the decision rights must be clear. Is the decision made by the CEO? Disclosure committee? GC and CFO jointly? Board committee? Define this before the incident.

What evidence is required for each decision?
Do not wait until the incident to decide what “enough evidence” means. Define minimum evidence packages for operational impact, financial exposure, customer harm, legal triggers, and confidence.

When is the board notified?
There should be multiple board escalation levels. Not every incident requires a full board meeting. Some require notice to the board risk chair. Some require briefing the audit committee. Some require a formal board call. Some require ongoing updates.

What gets documented?
Document the facts known at the time, the confidence level, the decision made, the alternatives considered, and the reason for the decision. This is not about creating paperwork. It is about preserving the reasoning of serious people making serious decisions under uncertainty.

Good decision records are concise. They should show that the organization had a process, used it, challenged assumptions, and updated decisions as facts changed.

That last point matters.

Materiality is not always a one-time decision. An incident can become material later. A decision that was reasonable at 10:00 a.m. may need to change at 4:00 p.m. because the facts changed.

That is not failure.

Failure is pretending the 10:00 a.m. answer is still valid after the evidence has moved.

Modeling Materiality With Bayesian Thinking

You do not need a Ph.D. in statistics to use Bayesian thinking in cyber governance.

At its core, Bayesian reasoning means updating your confidence as new evidence arrives.

That is exactly how incident response works when it is done well.

You start with a prior belief: based on the alert, threat actor, affected system, known exposure, and business context, how likely is this incident to create a material impact?

Then new facts arrive.

Logs show successful access. Confidence goes up.

No evidence of privilege escalation. Confidence goes down.

Threat actor is known for double extortion. Confidence goes up.

Endpoint telemetry shows containment before staging. Confidence goes down.

A customer-facing service is degraded. Confidence in operational impact goes up.

The affected system contains regulated data. Confidence in legal trigger goes up.

Backups are validated. Confidence in prolonged outage goes down.

This is not about reducing governance to a formula. It is about creating a disciplined way to avoid two common errors: panic and denial.

A simple model might score each impact category from 0 to 5 and confidence from 0 to 5.

For example:

  • Operational impact: 4
  • Financial exposure: 3
  • Customer harm: 2
  • Regulatory trigger: 3
  • Evidence confidence: 2

That may not yet support a final materiality conclusion, but it may absolutely support executive escalation, legal review, and board risk chair notification.

Later, new facts arrive:

  • Operational impact drops to 2 because service is restored.
  • Financial exposure remains 3 because customer credits are possible.
  • Customer harm rises to 4 because affected records are identified.
  • Regulatory trigger rises to 4.
  • Evidence confidence rises to 4.

Now the decision posture changes. The organization should not be surprised by that change. The model expected it.

The point is not mathematical precision. The point is decision discipline.

Boards do not need the CISO to pretend to know everything in hour two. They need the CISO, GC, and CFO to explain what is known, what is unknown, what could become true, what decisions are required now, and what evidence would change the decision.

That is the difference between technical reporting and enterprise risk leadership.

Four Examples

1. SaaS Outage

A SaaS provider experiences a production outage after a suspected malicious change to a deployment pipeline.

At first, there is no evidence of data access. The technical team believes the event is contained. The service, however, is unavailable to a large percentage of enterprise customers for several hours.

A traditional security view may focus on whether data was stolen.

A materiality view asks a broader set of questions:

  • Are customers unable to perform critical business functions?
  • Are service-level agreements implicated?
  • Will credits or penalties be owed?
  • Does the outage affect revenue recognition or churn risk?
  • Does the incident suggest a weakness in software supply chain controls?
  • Are customers contractually entitled to notice?

The event may be material even without confirmed data theft if the operational and financial consequences are significant enough.

2. Credit Union Fraud Event

A credit union detects account takeover activity affecting a limited number of members.

The dollar loss is initially modest. Security blocks the active campaign. On the surface, it may look like a contained fraud event.

But the materiality model asks different questions:

  • Does the attack reveal a systemic weakness in authentication?
  • Are members exposed to repeat fraud?
  • Are reimbursement obligations clear?
  • Is there a regulator notification requirement?
  • Could member trust be harmed in a way that affects deposits, lending, or reputation?
  • Is the event part of a broader pattern across peer institutions?

In financial services, trust is not soft. It is an asset. If cyber fraud undermines trust in core account access, the materiality discussion should not be limited to immediate loss.

3. Vendor Compromise

A trusted vendor announces that its environment was breached.

There is no evidence yet that your data was accessed. The vendor’s first notice is vague. Your own logs show unusual API activity, but nothing definitive.

This is where confidence modeling matters.

The event may begin as plausible third-party exposure. It may move to probable if logs show suspicious access patterns. It may become confirmed if the vendor identifies your data in the affected population.

The playbook should define what happens at each stage.

Waiting for the vendor to finish its investigation may not be acceptable if your own customers, regulators, or board need earlier risk awareness. At the same time, over-disclosing without evidence can create confusion and unnecessary harm.

The right move is structured escalation based on confidence, not vendor-driven helplessness.

4. AI Workflow Data Leak

An internal team uses an AI-enabled workflow tool to process customer support tickets. Later, the organization discovers that sensitive customer data may have been sent to a model or third-party platform outside approved controls.

There is no malware. No ransomware note. No classic intrusion.

But there may be data exposure, contractual violation, privacy risk, customer harm, and governance failure.

This is the kind of incident many older response plans handle poorly because they are built around breach archetypes from ten years ago.

Materiality engineering forces the right questions:

  • What data was processed?
  • Was it retained?
  • Was it used for training?
  • Was it exposed to other tenants or users?
  • Were customer commitments violated?
  • Was the AI workflow approved?
  • Does this reveal a broader control weakness in shadow AI adoption?

AI does not eliminate cyber materiality. It expands the places where material cyber risk can appear.

Build the Playbook, Then Rehearse the Ambiguity

The best next step is not to write a 90-page policy.

The best next step is to build a practical cyber materiality playbook.

It should include:

  • Materiality factors and scoring guidance
  • Escalation thresholds
  • Decision rights
  • Evidence minimums
  • Board notification paths
  • Disclosure committee procedures
  • Documentation templates
  • Scenario-specific trigger maps
  • A process for updating decisions as facts change

Then test it.

But do not test it with an easy tabletop where the facts are obvious and the answer is predetermined.

Test the gray areas.

Run a ransomware scenario where recovery is working but data exposure is unclear.

Run a vendor compromise where the vendor refuses to provide useful detail.

Run a SaaS outage where no data was stolen, but customers are materially impaired.

Run an AI data handling scenario where nobody knows whether the tool retained sensitive information.

Run a fraud scenario where the initial dollar amount is small but the control implication is large.

The purpose of the tabletop is not to “win.” The purpose is to expose where decision rights are vague, where evidence is missing, where executives talk past one another, and where the board would be surprised.

Surprise is the enemy of governance.

Final Thought

Cyber materiality is not a legal afterthought. It is an enterprise design problem.

The organizations that handle this well will not be the ones with the thickest incident response binder. They will be the ones that have already decided how to decide.

They will know which facts matter. They will know who has authority. They will know when to escalate. They will know how to brief the board without either minimizing or catastrophizing. They will understand that confidence changes as evidence arrives, and that good governance means updating the decision as the facts mature.

Most importantly, they will understand that cyber risk is not separate from enterprise value.

A cyber incident can affect revenue, trust, liquidity, operations, legal exposure, strategic execution, and leadership credibility. That makes materiality too important to improvise.

Do the hard thinking now.

Because during an incident, you do not rise to the level of your policy.

You fall to the level of your decision architecture.

More Info and Help

MSI helps organizations build practical, defensible cyber governance programs that connect security operations to executive decision-making, board oversight, regulatory expectations, and real-world business impact.

If your organization needs help developing a cyber materiality playbook, mapping incident escalation paths, preparing board-level tabletop exercises, or aligning cybersecurity risk with enterprise value, contact MSI.

We can help you engineer the decision process before the incident forces the issue.

 

 

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

Defending Small Credit Unions in the Age of AI-Driven Synthetic Fraud

Posted on by
Reply

We’ve seen fraud evolve before. We’ve weathered phishing, credential stuffing, card skimming, and social engineering waves—but what’s coming next makes all of that look like amateur hour. According to Experian and recent security forecasting, we’re entering a new fraud era. One where AI-driven agents operate autonomously, build convincing synthetic identities at scale, and mount adaptive, shape-shifting attacks that traditional defenses can’t keep up with.

For small credit unions and community banks, this isn’t a hypothetical future—it’s an urgent call to action.

SecureVault

The Rise of Synthetic Realities

Criminals are early adopters of innovation. Always have been. But now, 80% of observed autonomous AI agent use in cyberattacks is originating from criminal groups. These aren’t script kiddies with GPT wrappers—these are fully autonomous fraud agents, built to execute entire attack chains from data harvesting to cash-out, all without human intervention.

They’re using the vast stores of breached personal data to forge synthetic identities that are indistinguishable from real customers. The result? Hyper-personalized phishing, credential takeovers, and fraudulent accounts that slip through onboarding and authentication checks like ghosts.

Worse yet, quantum computing is looming. And with it, the shift from “break encryption” to “harvest now, decrypt later” is already in motion. That means data stolen today—unencrypted or encrypted with current algorithms—could be compromised retroactively within a decade or less.

So what can small institutions do? You don’t have the budget of a multinational bank, but that doesn’t mean you’re defenseless.

Three Moves Every Credit Union Must Make Now

1. Harden Identity and Access Controls—Everywhere

This isn’t just about enforcing MFA anymore. It’s about enforcing phishing-resistant MFA. That means FIDO2, passkeys, hardware tokens—methods that don’t rely on SMS or email, which are easily phished or intercepted.

Also critical: rethink your workflows around high-risk actions. Wire transfers, account takeovers, login recovery flows—all of these should have multi-layered checks that include risk scoring, device fingerprinting, and behavioral cues.

And don’t stop at customers. Internal systems used by staff and contractors are equally vulnerable. Compromising a teller or loan officer’s account could give attackers access to systems that trust them implicitly.

2. Tune Your Own Data for AI-Driven Defense

You don’t need a seven-figure fraud platform to start detecting anomalies. Use what you already have: login logs, device info, transaction patterns, location data. There are open-source and affordable ML tools that can help you baseline normal activity and alert on deviations.

But even better—don’t fight alone. Join information-sharing networks like FS-ISAC, InfraGard, or sector-specific fraud intel circles. The earlier you see a new AI phishing campaign or evolving shape-shifting malware variant, the better chance you have to stop it before it hits your members.

3. Start Your “Future Threats” Roadmap Today

You can’t wait until quantum breaks RSA to think about your crypto. Inventory your “crown jewel” data—SSNs, account histories, loan documents—and start classifying which of that needs to be protected even after it’s been stolen. Because if attackers are harvesting now to decrypt later, you’re already in the game whether you like it or not.

At the same time, tabletop exercises should evolve. No more pretending ransomware is the worst-case. Simulate a synthetic ID scam that drains multiple accounts. Roleplay a deepfake CEO fraud call to your CFO. Put AI-enabled fraud on the whiteboard and walk your board through the response.

Final Thoughts: Small Can Still Mean Resilient

Small institutions often pride themselves on their close member relationships and nimbleness. That’s a strength. You can spot strange behavior sooner. You can move faster than a big bank on policy changes. And you can build security into your culture—where it belongs.

But you must act deliberately. AI isn’t waiting, and quantum isn’t slowing down. The criminals have already adapted. It’s our turn.

Let’s not be the last to see the fraud that’s already here.

 

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

Antifragility in the Age of Cyber Extremistan

Posted on by
Reply

Why Building Cybersecurity Like the Human Immune System Is the Only Strategy That Survives the Unknown

Unnamed 4

We don’t live in “Mediocristan” anymore.

In the controlled world of Gaussian curves and predictable outcomes, most security strategies make sense—if you’re still living in the realm where human height and blood pressure are your biggest threats. But for cybersecurity practitioners, the real world looks more like “Extremistan”—the place where Black Swan events dominate, where a single breach can wipe out decades of effort, and where average behavior is not just irrelevant, it’s dangerously misleading.

That’s the world Nassim Taleb described in The Black Swan, and it’s the reality we live in every day as defenders of digital infrastructure.

And if you’re using traditional models to manage cyber risk in this world, you’re probably optimizing for failure.

From Robust to Antifragile: Why Survival Isn’t Enough

Taleb coined the term antifragile to describe systems that don’t just resist chaos—they improve because of it. It’s the difference between a glass that doesn’t break and a muscle that gets stronger after lifting heavy weight. Most security programs are designed to be robust—resilient under stress. But that’s not enough. Resilience still assumes a limit. Once you pass the red line, you break.

To thrive in Extremistan, we need to design systems that learn from stress, that benefit from volatility, and that get stronger every time they get punched in the face.

1. Security by Subtraction (Via Negativa)

In medicine, there’s a term called iatrogenics—harm caused by the treatment itself. Sound familiar? That’s what happens when a security stack becomes so bloated with overlapping agents, dashboards, and tools that it becomes its own attack surface.

Antifragile security starts with subtraction:

  • Decommission Legacy: Every unmonitored web server from 2009 you forgot about is a potential ruin event.

  • Minimize Privilege: If your domain admin group has more people than your bowling team, you’re in trouble.

  • Simplify, Aggressively: Complexity is fragility disguised as maturity.

Less isn’t just more—it’s safer.

2. Controlled Stressors: Hormesis for Systems

An immune system kept in a bubble weakens. One that’s constantly challenged becomes elite. The same goes for cyber defenses.

  • Red Teams as Immune Response Training: Stop treating red teams as adversaries. They’re your vaccine.

  • Chaos Engineering: Don’t just test recovery—induce failure. Intentionally break things. Break them often. Learn faster than your adversaries.

  • Study the Misses: Every alert that almost mattered is gold dust. Train on it.

This isn’t about drills. It’s about muscle memory.

3. The Barbell Strategy: Secure Boring + Wild Bets

One of Taleb’s more underappreciated ideas is the barbell strategy: extreme conservatism on one end, high-risk/high-reward exploration on the other. Nothing in the middle.

  • 90%: Lock down the basics. IG1 controls. Patching. Backups. Privilege minimization. The boring stuff that wins wars.

  • 10%: Invest in weird, bleeding-edge experiments. Behavioral traps. Decoy data. Offensive ML. This is your lab.

Never bet on “average” security tools. That’s how you end up with a little risk everywhere—and a big hole somewhere you didn’t expect.

4. Skin in the Game: Incentives That Matter

When the people making decisions don’t bear the cost of failure, systems rot from within.

  • Vendors Must Own Risk: If your EDR vendor can disclaim all liability for failure, they’ve got no skin in your game.

  • On-Call Developers: If they wrote the code, they stay up with it. The best SLAs are fear and pride.

  • Risk-Based Compensation: CISOs must have financial incentives tied to post-incident impact, not checkbox compliance.

Fragility flourishes in environments where blame is diffuse and consequences are someone else’s problem.

5. Tail Risk and the Absorbing Barrier

Most CIS frameworks are built to mitigate average risk. But in Extremistan, ruin is what you plan for. The difference? A thousand phishing attempts don’t matter if one spear phish opens the gates.

  • Design for Blast Radius: Assume breach. Isolate domains. Install circuit breakers in your architecture.

  • Plan for the Unseen: Run tabletop exercises where the scenario doesn’t exist in your IR plan. If that makes your team uncomfortable, you’re doing it right.

  • Offline Backups Are Sacred: If they touch the internet, they’re not a backup—they’re bait.

There are no do-overs after ruin.

6. Beware the Turkey Problem

A turkey fed every day believes the butcher loves him—until Thanksgiving. A network with zero incidents for three years might just be a turkey.

  • Continuous Validation, Not Annual Audits: Trust your controls as much as you test them.

  • Negative Empiricism: Don’t learn from the shiny success story. Learn from the company that got wrecked.

You are not safe because nothing has happened. You are safe when you have survived what should have killed you.

Unnamed 6

Closing Thought: Security as Immune System, Not Armor

If you’re still thinking of your security stack as armor—hard shell, resist all—you’re already brittle. Instead, think biology. Think immune system. Think antifragility.

Expose your system to small, survivable threats. Learn from every wound. Build muscle. Be lean, not large. Be hard to kill, not hard to touch.

In a world governed by Extremistan, the best cybersecurity strategy isn’t to avoid failure—it’s to get stronger every time you fail.

Because someday, something will break through. The question is—will you be better afterward, or gone completely?

 

 

 

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

Supply Chain Security Insights

Posted on by
Reply

Supply chain attacks are one of the most common cyber threats faced by organizations. They are costly and disruptive, often resulting in lost revenue and customer trust.

In this article, we’ll discuss five insights about supply chain attacks that all supply chain management and information security teams should be aware of.

#1. Supply Chains Can Be Vulnerable

Supply chains are complex networks of companies, suppliers, customers, and partners that provide goods and services to each other.

They include manufacturers, distributors, retailers, service providers, logistics providers, and others.

These entities may interact directly or indirectly via intermediaries such as banks, insurance companies, payment processors, freight forwarders, customs brokers, etc.

Supply chains are vulnerable to attack because they involve multiple parties and interactions between them. Each organization in the chain will have its own risk profile, security posture, and business model. This creates a complex environment for security risks. Attackers can target any part of the supply chain, and often focus on the weakest link, including manufacturing facilities, distribution centers, warehouses, transportation hubs, retail stores, etc.

Attackers can disrupt operations, steal intellectual property, damage reputation, and cause losses in revenue and profits.

#2. Supply Chain Security Must Include All Stakeholders

Supply chain security involves protecting against threats across the entire value stream. This means securing data, processes, systems, physical assets, personnel, and technology.

It also requires integrating security practices and technologies across the entire organization.

This includes ensuring that information sharing occurs among stakeholders, that employees understand their roles and responsibilities, and that policies and procedures are followed.

Security professionals should collaborate closely with executives, managers, and staff members to ensure that everyone understands the importance of security and has ownership over its implementation.

#3. Supply Chain Security Requires Ongoing Monitoring and Maintenance

Supply chain security requires ongoing monitoring and maintenance.

An effective approach is to continuously monitor the status of key indicators, assess risks, identify vulnerabilities, and implement countermeasures.

For example, an attacker could attempt to compromise sensitive data stored in databases, websites, mobile apps, and other locations.

To prevent these incidents, security teams should regularly review logs, audit reports, and other intelligence sources to detect suspicious activity.

They should also perform penetration tests, vulnerability scans, and other assessments to uncover potential weaknesses.

#4. Supply Chain Security Requires Collaboration Across Organizations

A single department cannot manage supply chain security within an organization.

Instead, it requires collaboration across departments and functional areas, including IT, finance, procurement, human resources, legal, marketing, sales, and others.

Each stakeholder must be responsible for maintaining security, understanding what constitutes acceptable behavior, and implementing appropriate controls.

Collaborating across organizational boundaries helps avoid silos of knowledge and expertise that can lead to gaps in security awareness and training.

#5. Supply Chain Security Is Critical to Organizational Success

Organizations that fail to protect their supply chains face significant financial penalties.

A recent study found that supply chain breaches cost United States businesses $6 trillion annually.

That’s equivalent to nearly 10% of the annual global GDP.

Supply chain attacks can result in lost revenues, damaged reputations, and increased costs.

Companies that invest in supply chain security can significantly improve operational efficiency, productivity, profitability, and brand image.

Three Things I’ve Learned About Credit Union Risk Management

Posted on by
Reply

I have been working with Credit Unions for more than 20 years and have done a wide variety of information security and risk management work over that time. I’ve worked with technical teams, management and boards over the span of more than two decades. Here are three things I’ve learned about how CUs manage risk during that time. 

1) Most credit unions that I’ve worked with care just as much, if not more, about information security than most of the regional size banks they often compete with.

I’ve heard more than one CU leader tell me that they have to be better than the banks, because when a bank gets hacked – that bank makes the news and feels the impact. However, he said, when a credit union gets hacked – all credit unions suffer from the bad press. I am not sure the data supports his claim, but it’s an example of how CUs often focus on working together to solve big problems, and put a lot more attention to detail into it.

2) Many of the credit unions I have worked with look at information security and threat awareness as something that they can offer to their members (“customers, in bank speak”).

More than a few of the CUs have engaged so deeply with their customers on phishing and identify theft, that they include them in discussions about what products and services the CU buys. They do trials, include members in beta-tests and I’ve even seen them do onsite training for how to use new multi-factor authentication tools – even ones that weren’t in use at the CU – just to help make the members more secure and reduce the threat of password re-use across personal sites.

3) The board is often more involved in the risk management process at my CU clients than my banking clients.

The NCUA has taken a lot of steps to increase board member awareness about information security, and it often shows at credit unions. Several times a year, I am asked to present threat updates or review the information security program of a CU, specifically with a presentation to the board in mind. I am often engaged as a third party, to spend a couple of days looking at a security program and reporting to the board on it’s maturity and areas of potential improvement.

During these board sessions, it is not uncommon for the board questions to last more than an hour, after the presentation has completed. The point is, most CU boards that I have worked with are deeply engaged in thinking about risk management at the credit union.

For those of you interested in more about risk management at credit unions, here are some of the best sources, which I refer to often in my presentations:

  • Credit unions also face such internal risks as internal fraud, legal and regulatory noncompliance, data breaches, and injuries to staff and visitors. (boardeffect.com)

  • The bottom line: Figuring out the risk appetite will help guide credit unions to create realistic and measurable risk guidelines. (visibleequity.com)

  • We have helped Credit Unions develop risk appetite statements and risk frameworks and can work with your Credit Union to develop the documentation you require. (creditunionupdate.com)

If you’d like to learn more about MSI and our work with credit unions, just drop us a line (info@microsolved.com) or give us a call (614-351-1237) and we’d be happy to talk about how we might be able to help your credit union excel in IT risk management.

A Quick Expert Conversation About Gap Assessment

Posted on by
Reply

Gap Assessment Interview with John Davis

What follows is a quick interview session with John Davis, who leads the risk assessment/policy/process team at MicroSolved. We completed the interview in January of 2020, and below are the relevant parts of our conversation.

Brent Huston: “Thanks for joining me today, John. Let’s start with what a gap assessment is in terms of HIPAA or other regulatory guidance.”

John Davis: “Thanks for the chance to talk about gap assessment. I have run into several HIPAA concerns such as hospitals and health systems who do HIPAA gap analysis / gap assessment in lieu of HIPAA risk assessment. Admittedly, gap assessment is the bulk of risk assessment, however, a gap assessment does not go to the point of assigning a risk rating to the gaps found. It also doesn’t go to the extent of addressing other risks to PHI that aren’t covered in HIPAA/HITECH guidance.”

BH: “So, in some ways, the gap assessment is more of an exploratory exercise – certainly providing guidance on existing gaps, but faster and more affordable than a full risk assessment? Like the 80/20 approach to a risk assessment?”

John Davis: “I suppose so, yes. The price is likely less than a full blown risk assessment, given that there is less analysis and reporting work for the assessment team. It’s also a bit faster of an engagement, since the deep details of performing risk analysis aren’t a part of it.”

BH: “Should folks interested in a gap assessment consider adding any technical components to the work plan? Does that combination ever occur?”

JD: “I can envision a gap assessment that also includes vulnerability assessment of their networks / applications. Don’t get me wrong, I think there is immense value in this approach. I think that to be more effective, you can always add a vulnerability assessment to gauge how well the policies and processes they have in place are working in the context of the day-to-day real-world operations.”

BH: “Can you tie this back up with what a full risk assessment contains, in addition to the gap assessment portion of the work plan?”

JD: “Sure! Real risk assessment includes controls and vulnerability analysis as regular parts of the engagement. But more than that, a complete risk assessment also examines threats and possibilities of occurrence. So, in addition to the statement of the gaps and a roadmap for improvement, you also get a much more significant and accurate view of the data you need to prioritize and scope many of the changes and control improvements needed. In my mind, it also gets you a much greater view of potential issues and threats against PHI than what may be directly referenced in the guidance.” 

BH: “Thanks for clarifying that, John. As always, we appreciate your expert insights and experience.”

JD: “Anytime, always happy to help.”

If you’d like to learn more about a gap assessment, vulnerability assessment or a full blown risk assessment against HIPAA, HITECH or any other regulatory guidance or framework, please just give us a call at (614) 351-1237 or you can click here to contact us via a webform. We look forward to hearing from you. Get in touch today! 

Tips on Reducing Human Error Risks

Posted on by
5

One of the largest risks that organizations face is human error. The outcome of human errors show themselves in security, architecture, business operations, IT & non-IT projects, etc. The list goes on and on. You can read more about the impacts of human error on infosec here and here.

It’s important to understand some of the reasons why these errors occur, especially when critical projects or changes are being considered.

Some of the high level things to think about:

  • Physical fatigue – this is likely the leading cause of human errors, workers may not be getting enough sleep or downtime, especially during critical projects when stress and demands may be high, not to speak of their personal lives – organizations should allow for key resources to have adequate downtime to reduce errors during critical projects
  • Decision fatigue – the more decisions that someone has to make, the worse their decisions get over time – just like physical fatigue, preserving their decision making capability should be a consideration during critical projects for key resources
  • Lack of time on task – in many organizations, critical project key personnel are often called to meeting after meeting to discuss, plan or execute parts of the project – when this minimizes their time on task to perform the research, work or development for the project then quality suffers – at the very least, it may aggravate the other problems of fatigue; organizations should focus key resources on time on task to up the quality of their work during critical projects
  • Lack of peer review – peer review is an essential control for human error, since it can catch such usual conditions as typos, missing words, simple mistakes in logic, etc. Critical projects should always include several layers of peer review to ensure higher quality of the process or outcome
  • Lack of preparation for failure – many critical projects suffer from this form of error as many people assume that their plans will be successful, but failure occurs often, and the more complex the systems or plans, the more likely it is to occur – have a contingency plan to prevent emotional decisions which can deeply impact quality and successful outcomes

There are many other issues around human error in critical projects and even more in day to day operations. But, these seem to be the most prevalent and immediate issues we see around critical projects with clients in the last few years. 

How does your team manage human errors? What controls have you implemented? Share with us on Twitter (@microsolved, @lbhuston) and we may write about it in future posts. As always, thanks for reading! 

80/20 Rule of Information Security

Posted on by
4

After my earlier this post about the SDIM project, several people on Twitter also asked me to do the same for the 80/20 Rule of Information Security project we completed several years ago. 

It is a list of key security projects, their regulatory mappings, maturity models and such. Great for building a program or checking yours against an easy to use baseline.

Thanks for reading, and here is where you can learn more about the 80/20 project. Click here.

3 Reasons Your Supply Chain Security Program Stinks

Posted on by
3
  1. Let’s face it, Supply Chain Security and Vendor Risk Management is just plain hard. There are a lot of moving pieces – companies, contacts, agreements, SLAs, metrics, reporting, etc. Suppliers also change frequently, since they have their own mergers/acquisitions, get replaced due to price changes or quality issues, new suppliers are added to support new product lines and old vendors go away as their product lines become obsolete. Among all of that, is cyber-security. MSI has a better and faster way forward – an automated way to reduce the churn – a way to get a concise, easy to use and manageable view of the security of your vendors’ security posture. This month, we will show you what we have been doing in secret for some of the largest companies in the world… 
  2. Vendors with good security postures often look the same as vendors with dangerous security postures, on paper at least. You know the drill – review the contracts, maybe they send you an audit or scan report (often aged), maybe they do a questionnaire (if you’re lucky). You get all of this – after you chase them down and hound them for it. You hope they were honest. You hope the data is valid. You hope they are diligent. You hope they stay in the same security posture or improve over time, and not the opposite. You hope for a lot. You just don’t often KNOW, and what most companies do know about their vendors is often quite old in Internet terms, and can be far afield from where their security posture is at the moment. MSI can help here too. This month, we will make our passive assessment tool available to the public for the first time. Leveraging it, you will be able to rapidly, efficiently and definitively get a historic and current view of the security posture of your vendors, without their permission or knowledge, with as frequent updates as you desire. You’ll be able to get the definitive audit of their posture, from the eyes of an attacker, in a variety of formats – including direct data feeds back into your GRC tools. Yes, that’s right – you can easily differentiate between good and bad security AND put an end to data entry and keyboarding sessions. We will show you how… 
  3. Supply chain security via manual processes just won’t scale. That’s why we have created a set of automated tools and services to help organizations do ongoing assessments of their entire supply chain. You can even sort your supply chain vendors by criticality or impact, and assign more or less frequent testing to those groups. You can get written reports, suitable for auditors – or as we wrote above, data feeds back to your GRC tools directly. We can test tens of vendors or thousands of vendors – whatever you need to gain trust and assurance over your supply chain vendors. The point is, we built workflows, methodologies, services and tools that scale to the largest companies on the planet. This month, we will show you how to solve your supply chain security problems.
 
If you would like a private, sneak peak preview briefing of our research and the work we have done on this issue, please get in touch with your account executive or drop us a line via info (at) microsolved /dot/ com, call us at (614) 351-1237 or click the request a quote button at the top of our website – http://microsolved.com. We’ll be happy to sit down and walk through it with you. 
 
If you prefer to learn more throughout March – stay tuned to https://stateofsecurity.com for more to come. Thanks for reading! 

Comparing 2 Models for DMZ Implementations

Posted on by
7
I recently had a discussion with another technician about the security of the two most popular DMZ implementation models. That is: 
  • The “3 Legged Model” or “single firewall” – where the DMZ segment(s) are connected via a dedicated interface (or interfaces) and a single firewall implements traffic control rules between all of the network segments (the firewall could be a traditional firewall simply enforcing interface to interface rules or a “next generation” firewall implementing virtualized “zones” or other logical object groupings)
  • The “Layered Model” or “dual firewall”- where the DMZ segment(s) are connected between two sets of firewalls, like a sandwich
 
Both approaches are clearly illustrated above, and explained in detail in the linked wikipedia article, so I won’t repeat that here. 
 
I fully believe that the “3 Legged Model” is a lower risk implementation than the layered model. This outright contradicts what the wikipedia article above states: 
 
     “The most secure approach, according to Stuart Jacobs, [1]is to use two firewalls to create a DMZ.” — wikipedia article above.
 
While the Layered model looks compelling at first blush, and seems to apply the concept of “more firewalls would need to be compromised to lead to internal network access”; I believe that, in fact, it reduces the overall security posture in the real world, and increases risk. Here’s why I feel that way. Two real-world issues that often make things that look great at first blush or that “just work” in the lab environment, have significant disadvantages in the real world are control complexity and entropy. Before we dig too deeply into those issues though, let’s talk about how the two models are similar. (Note that we are assuming that the firewalls themselves are equally hardened and monitored – IE, they have adequate and equal security postures both as an independent system and as a control set, in aggregate.)
 
Reviewing the Similarities
 
In both of the models, traffic from the DMZ segment(s) pass through the firewall(s) and traffic controls are applied. Both result in filtered access to the internal trusted network via an often complex set of rules. Since in both cases, traffic is appropriately filtered, authorization, logging and alerting can adequately occur in both models. 
 
Establishing Differences
 
Now the differences. In the 3 Legged model, the controls are contained in one place (assuming a high availability/failover pair counts as a single set of  synced controls), enforced in one place, managed and monitored in one place. The rule set does not have cascading dependencies on other implementations of firewalls, and if the rule set is well designed and implemented, analysis at a holistic level is less complex.
 
In the Layered model, the controls are contained across two separate instances, each with different goals, roles and enforcement requirements. However, the controls and rule sets are interdependent. The traffic must be controlled through a holistic approach spread across the devices, and failures at either firewall to adequately control traffic or adequately design the rule sets could cause cascading unintended results. The complexity of managing these rules across devices, with different rule sets, capabilities, goals and roles is significantly larger than in a single control instance. Many studies have shown that increased control complexity results in larger amounts of human error, which in turn contributes to higher levels of risk. 
 
Control Complexity Matters
 
Misconfigurations, human errors and outright mistakes are involved in a significant number (~95%) of compromises. How impactful are human mistakes on outright breaches? Well according to the 2015 Verizon DBIR:
 
“As with years past, errors made by internal staff, especially system administrators who were the prime actors in over 60% of incidents, represent a significant volume of breaches and records ,even with our strict definition of what an “error” is.” —DBIR
 
Specifically, misconfiguration of devices were involved in the cause of breaches directly in 3.6% of the breaches studied in the DBIR. That percentage may seem small, but the data set of 79,790 incidents resulting in 2,122 breaches that means a staggering number of 76 breaches of data were the result of misconfigurations.
 
This is exactly why control complexity matters. Since control complexity correlates with misconfiguration and human error directly, when complexity rises, so does risk – conversely, when controls are simplified, complexity falls and risk of misconfiguration and human error is reduced.
 
Not to beat on the wikipedia article and Stuart Jacob’s assertions, but further compounding the complexity of his suggestion is multiple types of firewalls, managed by multiple vendors. Talk about adding complexity, take an interdependent set of rules and spread them across devices, with differing roles and goals and you get complexity. Now make each part of the set a different device type with it’s own features, nuances, rule language, configuration mechanism and managed service vendor, and try to manage both of those vendors in sync to create a holistic implementation of a control function. What you have is a NIGHTMARE of complexity. At an enterprise scale, this implementation approach would scale in complexity, resources required and oversight needs logarthmically as new devices and alternate connections are added. 
 
So, which is less complex, a single implementation, on a single platform, with a unified rule set, managed, monitored and enforced in a single location – OR – a control implemented across multiple devices, with multiple rule sets that require monitoring, management and enforcement in interdependent deployments? I think the choice is obvious and rational.
 
Now Add Entropy
 
Ahh, entropy, our inevitable combatant and the age old foe of order. What can you say about the tendency for all things to break down? You know what I am about to point out though, right? Things that are complex, tend to break down more quickly. This applies to complex organisms, complex structures, complex machinery and complex processes. It also applies to complex controls.
 
In the case of our firewall implementation, both of our models will suffer entropy. Mistakes will be made. Firewall rules will be implemented that allow wider access than is needed. Over time, all controls lose efficiency and effectiveness. Many times this is referred to as “control drift” or “configuration drift”. In our case, the control drift over a single unified rule set would have a score of 1. Changes to the rule set, apply directly to behavior and effectiveness. However, in the case of the Layered model, the firewalls each have a distinct rule set, which will degrade – BUT – they are interdependent on each other – giving an effective score of 2 for each firewall. Thus, you can easily see, that as each firewall’s rule set degrades, the private network’s “view” of the risk increases significantly and at a more rapid pace. Simply put, entropy in the more complex implementation of multiple firewalls will occur faster, and is likely to result in more impact to risk. Again, add the additional complexity of different types of firewalls and distinct vendors for each, and the entropy will simply eat you alive…
 
Let’s Close with Threat Scenarios

Let’s discuss one last point – the actual threat scenarios involved in attacking the private network from the DMZ. In most cases, compromise of a DMZ host will give an attacker a foothold into the environment. From there, they will need to pivot to find a way to compromise internal network resources and establish a presence on the internal network. (Note that I am only focusing on this threat scenario, not the more common phishing/watering hole scenarios that don’t often involve the compromise of a DMZ host, except perhaps for exfiltration paths. But, this is outside our current scope.) If they get lucky, and the DMZ is poorly designed, they may find that their initially compromised host has some form of access to the internal network that they can exploit. But, in most cases, the attacker needs to perform lateral movement to compromise additional hosts, searching for a victim that has the capability to provide a launching point for attacks against the internal network.
 
In these cases, detection is the goal of the security team. Each attacker move and probe, should cause “friction” against the controls, thereby raising the alert and log levels and the amount of unusual activity. Ultimately, this should lead to the detection of the attacker presence and the incident response process engagement.
 
However, let’s say that you are the attacker, trying to find a host that can talk to the internal network from the DMZ in a manner that you can exploit. How likely are you to launch an attack against the firewalls themselves? After all, these are devices that are designed for security and detection. Most attackers, ignore the firewalls as a target, and continue to attempt to evade their detection capabilities. As such, in terms of the threat scenario, additional discreet firewall devices, offer little to no advantage – and the idea that the attacker would need to compromise more devices to gain access loses credibility. They aren’t usually looking to pop the firewall itself. They are looking for a pivot host that they can leverage for access through whatever firewalls are present to exploit internal systems. Thus, in this case, both deployment models are rationally equal in their control integrity and “strength” (for lack of a better term).
 
Wrapping This Up
 
So, we have established that the Layered model is more complex than the 3 Legged model, and that it suffers from higher entropy. We also established that in terms of control integrity against the most common threat scenario, the implementation models are equal. Thus, to implement the Layered model over the 3 Legged model, is to increase risk, both initially, and at a more rapid pace over time for NO increase in capability or control “strength”. This supports my assertion that the 3 Legged model is, in fact, less risky than the Layered model of implementation.
 
As always, feel free to let me know your thoughts on social media. I can be found on Twitter at @lbhuston. Thanks for reading!