Tag Archives: risk

Vendor Evidence Is Now a Cyber Materiality Risk

Posted on by
Reply

A cybersecurity incident does not care where your data lives.

It does not care that the affected application is vendor-managed. It does not care that the logs are in a SaaS console your team cannot access. It does not care that the data-flow diagram is maintained by procurement, that customer-impact details live with a managed service provider, or that the outage timeline depends on a third-party support ticket.

But your materiality decision may care very much.

Public companies must disclose material cybersecurity incidents on Form 8-K within four business days after determining that the incident is material. The SEC’s rule also requires disclosure of the material aspects of the incident’s nature, scope, timing, and impact or reasonably likely impact, and the materiality determination must be made without unreasonable delay after discovery. 

That creates a practical problem many organizations have not fully internalized:

The disclosure clock may be yours, but the evidence may belong to someone else.

That is not just a legal nuance.

It is an operational design problem.

It is a governance problem.

And for SaaS-heavy companies, outsourced operations, cloud-native environments, managed-service-dependent companies, and public-company risk committees, it may be one of the most important cyber resilience problems to solve before the next incident.

Bugclipart

Materiality Fails When the Evidence Lives Somewhere Else

Cyber materiality is often discussed as if the company simply needs to “make the call.”

Is the incident material?

Is it reportable?

Does it affect revenue, customers, operations, liquidity, legal exposure, forecasts, trust, or the total mix of information available to investors?

Those are the right questions.

But in a real incident, the organization may not control the facts needed to answer them.

The affected identity provider may hold the authentication logs. The SaaS platform may hold the tenant access history. The managed detection provider may hold the alert timeline. The cloud service provider may hold the control-plane evidence. The payroll processor may hold the employee-impact facts. The e-commerce platform may hold failed transaction data. The CRM vendor may hold customer records, access logs, and data-export history.

So the internal team gathers in the war room and begins asking questions that sound simple:

What happened?

When did it start?

What systems were affected?

What data was involved?

Which customers were impacted?

Was there unauthorized access?

Was there exfiltration?

How long were services impaired?

What is the financial exposure?

What do we know, what do we believe, and what can we prove?

Then the uncomfortable answer arrives:

“We have asked the vendor.”

That is not evidence.

That is a dependency.

The Evidence Supply Chain Now Extends Outside the Enterprise

In a prior State of Security article, we discussed the need for a cyber materiality data plane: a way to produce evidence that is timely, traceable, and business-relevant before the incident occurs. That article framed materiality as an evidence supply-chain problem, not merely a decision-making problem. A useful cyber materiality data plane should answer where evidence came from, who owns it, how fresh it is, how confident the organization is in it, and what would change the organization’s mind. 

But many organizations stop that thinking at the boundary of their own environment.

That boundary is no longer real.

Modern enterprises are not built as clean internal systems surrounded by a hard perimeter. They are ecosystems of SaaS platforms, APIs, managed services, business process outsourcers, cloud providers, data processors, payment systems, logistics partners, file-transfer tools, identity brokers, AI services, and embedded technology providers.

The business process may be yours.

The customer relationship may be yours.

The regulatory obligation may be yours.

The investor disclosure obligation may be yours.

But the evidence may be distributed across ten companies, three ticketing systems, two legal teams, and one vendor support portal that does not understand your disclosure timeline.

That is where materiality decisions start to fail.

Not because the CISO is asleep.

Not because legal is slow.

Not because the CFO does not understand risk.

Because the organization has confused vendor assurance with vendor evidence reliability.

Those are not the same thing.

Questionnaires Are Not Evidence Pipelines

Most companies are not ignoring third-party risk.

They send vendor questionnaires. They review SOC 2 reports. They negotiate incident-notification clauses. They ask about encryption, backups, access controls, business continuity, vulnerability management, subcontractors, and data retention. They collect certificates of insurance. They maintain third-party risk ratings. They run annual reviews. They may even have cyber insurance retainers and outside counsel ready to go.

All of that is useful.

None of it guarantees that decision-quality evidence will arrive inside a live incident window.

That is the gap.

A vendor review often proves that a process exists.

It does not prove that the vendor can produce the specific logs, timelines, access records, data-flow facts, customer-impact details, and confidence statements needed to support your materiality decision while the facts are still moving.

There is a difference between asking:

“Do you have an incident response process?”

And asking:

“Within four hours of a suspected incident affecting our tenant, can you provide a timestamped evidence packet showing affected systems, affected data stores, administrative access activity, customer-impact scope, outage timeline, known gaps, confidence level, and named evidence owner?”

The first question belongs in a questionnaire.

The second belongs in a materiality evidence architecture.

Most companies have a lot of the first.

They have far less of the second.

The Third-Order Consequence: Your Vendor’s Evidence Problem Becomes Your Governance Problem

The first-order consequence of a vendor incident is usually operational.

A platform is down. A workflow is impaired. A system is unavailable. A user population is affected.

The second-order consequence is business impact.

Orders are delayed. Customers cannot log in. Employees cannot be paid. Support volume rises. Revenue recognition gets complicated. Contractual service levels are missed. A regulated process is interrupted.

The third-order consequence is governance failure.

Executives cannot determine materiality because the facts needed to make the decision are outside the company’s direct control.

That is the consequence that does not show up clearly enough in many third-party risk programs.

A vendor can be secure enough to pass procurement but still unreliable as an evidence source during a materiality event.

A vendor can have a clean SOC 2 report but still be slow, vague, or contractually constrained when asked for tenant-specific incident facts.

A vendor can meet its generic notification obligation but fail to provide the level of detail your disclosure committee, board, outside counsel, CFO, and CISO need to make a defensible decision.

That is why vendor evidence reliability should be treated as a governance control.

Not just a security control.

Not just a procurement requirement.

A governance control.

The Vendor Evidence Packet

For critical vendors, the organization should define a minimum evidence packet before the incident.

This does not need to be a 90-page document. It needs to be specific enough that everyone understands what “useful” means when the clock is moving.

A practical vendor evidence packet should answer these questions:

What happened?

What type of incident occurred? Which service was affected? Which tenant, environment, region, customer segment, or workflow may be involved? What is the known or suspected start time? When was the issue detected? What is the current containment status?

What evidence supports that statement?

Which logs, alerts, access records, system events, administrative actions, network activity, API activity, file-access events, data-export records, and monitoring outputs support the current understanding?

What data or business process was involved?

Which data categories may be affected? Is regulated data involved? Which business workflows depend on the affected service? Which customer, employee, supplier, or partner populations may be impacted?

What was the impact timeline?

When did service degradation begin? When did the outage start? Were transactions delayed, lost, duplicated, or failed? Were customer-facing functions unavailable? Were manual workarounds used? When was service restored? What residual impairment remains?

Who touched the environment?

Was there vendor administrative access? Customer administrative access? Subprocessor access? Emergency access? Support activity? Privileged activity? Anomalous authentication? API token activity? Service-account activity?

What is unknown?

Which logs are unavailable? Which systems have not yet been reviewed? Which data stores are not yet classified? Which subprocessors have not yet responded? Which assertions depend on incomplete forensic work?

How confident is the vendor?

For each major assertion, the vendor should provide a confidence level and the basis for that confidence. “We do not believe customer data was affected” is not enough. The organization needs to know what that belief is based on.

Who owns updates?

There should be a named vendor evidence owner, a technical escalation contact, a legal contact, an executive escalation path, and a defined update cadence.

That last point matters.

During an incident, “the vendor” is not an owner.

It is a fog bank.

Materiality decisions require named people, named evidence, timestamps, and confidence levels.

Evidence SLAs Should Sit Beside Security SLAs

Many contracts define security obligations.

Fewer define evidence obligations.

That needs to change.

For critical vendors, incident-notification language should not stop at “we will notify you without undue delay” or “within 72 hours.” Notification is not enough. A notice that says “we are investigating a security incident that may affect your environment” may satisfy the beginning of a process, but it does not support a materiality decision.

A more mature contract asks for evidence performance.

For example:

Which logs will be available?

How far back will they go?

In what format will they be delivered?

Are logs tenant-specific?

Are timestamps normalized?

Will administrative access be distinguishable from customer activity?

Will subprocessor activity be identified?

Will the vendor provide outage and degradation timelines?

Will customer-impact metrics be made available?

Will the vendor identify what is unknown or unavailable?

How quickly will updates be provided?

Who can authorize expedited disclosure support?

How will privilege, confidentiality, and regulatory constraints be handled?

This is not about turning every vendor into your forensic team.

It is about knowing, before the incident, whether the vendor can produce the evidence your organization needs to govern itself.

That is the bar.

Not Every Vendor Matters the Same Way

This is where systems thinking helps.

Do not start by treating every third party equally. That creates paperwork, not resilience.

Start by identifying vendors that are materiality-relevant.

A vendor may be materiality-relevant because it supports a critical business process. It may be materiality-relevant because it stores sensitive or regulated data. It may be materiality-relevant because its outage would affect customers, revenue, operations, safety, liquidity, or market confidence. It may be materiality-relevant because it is the only source of evidence for an important decision.

That last category is easy to miss.

Some vendors are not just operational dependencies.

They are evidence dependencies.

If the only reliable access logs for a customer-facing workflow live with the SaaS provider, that provider is an evidence dependency.

If the only transaction failure data lives with the payment processor, that processor is an evidence dependency.

If the only administrative activity history lives with the managed service provider, that provider is an evidence dependency.

If the only data-flow understanding lives in a vendor implementation document from three years ago, that vendor relationship is now a materiality weakness.

Classify vendors not only by inherent risk, data sensitivity, and spend.

Classify them by evidence criticality.

The Board Should Ask Different Questions

Boards and risk committees do not need to become incident handlers.

But they should ask better governance questions.

Not merely:

“Do we review our vendors?”

Ask:

“Which vendors are critical to cyber materiality decisions?”

Not merely:

“Do our contracts require incident notification?”

Ask:

“Do our contracts require decision-quality evidence within the timeframes our executives need?”

Not merely:

“Do we receive SOC 2 reports?”

Ask:

“Have we tested whether our most critical vendors can produce tenant-specific logs, access records, outage timelines, and customer-impact facts during a live incident?”

Not merely:

“Do we have a cyber incident response plan?”

Ask:

“Have we rehearsed a materiality decision where the most important facts are controlled by a third party?”

Those questions change the conversation.

They move vendor risk from annual compliance review to enterprise decision readiness.

That is where it belongs.

Tabletop the Vendor Evidence Gap

Most cyber tabletop exercises are too clean.

The malware is obvious. The timeline is scripted. The affected systems are known. The data exposure is eventually confirmed. The vendor cooperates just enough to let the exercise move forward.

That is not how many real incidents feel.

A better tabletop introduces vendor evidence friction.

Run the scenario where the vendor says your tenant was not affected, but cannot provide logs for twelve hours.

Run the scenario where the SaaS provider confirms an outage but will not yet confirm whether administrative access occurred.

Run the scenario where the managed service provider says the alert was contained, but your internal telemetry shows suspicious activity after the containment time.

Run the scenario where the vendor’s contract requires notification, but not the customer-impact data finance needs.

Run the scenario where customer support sees impact before the vendor status page changes.

Run the scenario where the vendor’s legal team controls all communications and the technical team is not allowed to join your incident bridge.

That is where the real learning happens.

The point is not to embarrass the vendor.

The point is to discover whether your materiality process depends on evidence you cannot obtain, cannot validate, or cannot interpret in time.

You want to find that out during an exercise.

Not on day one of a real event.

A Practical Model for Vendor Evidence Reliability

A useful model can be simple.

For each critical vendor, document five things.

1. Evidence Needed

Define the minimum evidence needed to support a materiality decision. Include logs, data categories, access records, timelines, outage metrics, affected users, affected customers, business functions, and known unknowns.

2. Evidence Source

Identify where each fact comes from. Is it in your SIEM? The vendor console? A vendor support ticket? A managed service portal? A cloud audit log? A contract repository? A business owner’s spreadsheet?

Evidence without provenance becomes opinion under pressure.

3. Evidence Owner

Assign internal and vendor-side owners. A vendor manager may own the relationship, but not the logs. A system owner may understand the workflow, but not the contractual notice requirement. A CISO may understand the risk, but not the revenue exposure.

Ownership has to be explicit.

4. Evidence Timing

Define how quickly each evidence type must be available. Some facts are needed in the first hour. Others are needed by the first executive briefing. Others are needed before a disclosure committee meeting. Others may arrive later and update the decision.

Timing is part of materiality architecture.

5. Evidence Confidence

Score the confidence of the evidence. Direct logs from authoritative systems are different from vendor assertions. Tenant-specific evidence is different from platform-wide generalities. Current evidence is different from stale evidence. Corroborated evidence is different from a status page.

The goal is not perfect certainty.

The goal is decision discipline.

What Leaders Should Do Now

This problem does not get solved during a live incident.

It gets solved in procurement, vendor-risk governance, tabletop design, incident response planning, contract negotiation, business-impact mapping, logging architecture, and board oversight.

A practical starting point looks like this:

Identify the top vendors that support critical business services.

Map which materiality-relevant facts depend on those vendors.

Determine whether current contracts require notification or actual evidence.

Review whether vendor logs are accessible, exportable, tenant-specific, and retained long enough to matter.

Test escalation paths before an incident.

Add vendor evidence delays and contradictions to tabletop exercises.

Build a confidence-scoring model for vendor-provided assertions.

Define what the organization will do when vendor evidence is late, incomplete, or unavailable.

That last item matters.

A decision process that requires perfect evidence is not a decision process.

It is a delay mechanism.

The organization needs to know how it will reason under uncertainty, how it will document that reasoning, and how it will update conclusions as new facts arrive.

Trust the Vendor Relationship. Verify the Evidence.

There is a temptation to treat this topic as adversarial.

It does not need to be.

Good vendors want to support their customers during incidents. Good customers know that vendors are also operating under pressure, legal review, incomplete facts, and their own incident response constraints.

But trust does not remove the need for evidence.

A mature organization can preserve the vendor relationship while still insisting on clear evidence expectations.

That means procurement, legal, security, finance, privacy, compliance, and the business owner all need to align before the incident.

The CISO cannot solve this alone.

The GC cannot solve this alone.

The vendor-risk team cannot solve this alone.

The CFO cannot model business impact if the operational facts are missing.

The board cannot oversee a decision process that has not been engineered.

Vendor evidence reliability is a shared enterprise responsibility.

More Information and Help from MicroSolved, Inc.

MicroSolved, Inc. helps organizations solve hard security, risk, and resilience problems through governance, advisory, assessment, response, research, and evidence-producing security work. MSI’s approach is built around practical guidance, experienced security judgment, ethical analysis, and helping organizations move from opinion to action. 

For organizations concerned about cyber materiality, vendor evidence gaps, third-party incident dependencies, or board-level cyber governance, MSI can help turn this from an abstract concern into a working program.

Areas where MSI can assist include:

Cyber Materiality Evidence Supply-Chain Assessments

MSI can help identify which systems, vendors, data sources, logs, workflows, and business-impact signals are required to support materiality decisions. The goal is to understand where evidence comes from, who owns it, how reliable it is, how quickly it can be produced, and where confidence is weak.

Vendor Evidence Reliability Reviews

MSI can help evaluate critical vendors not only for security posture, but also for evidence readiness. That includes reviewing whether the vendor can produce tenant-specific logs, access histories, outage timelines, data-impact facts, subprocessor information, customer-impact metrics, and confidence-scored updates during a live incident.

Incident Response and Ransomware Readiness

MSI provides incident response and threat-hunting support, and can help organizations prepare for the evidence demands of high-pressure cyber events. That includes identifying gaps in escalation, communication, containment, forensic readiness, and executive decision support. 

Executive and Board-Level Tabletop Exercises

MSI can design tabletop exercises that move beyond technical containment and into business decision-making. For this issue, that means simulating vendor delays, contradictory evidence, incomplete logs, uncertain customer impact, disclosure pressure, and board-level materiality questions.

vCISO and Board Advisory Support

MSI provides vCISO and board advisory services that can help organizations mature their cyber governance programs, strengthen oversight, and connect technical security realities to executive-level risk decisions. 

Third-Party and SaaS Incident Escalation Planning

MSI can help organizations define vendor escalation paths, evidence packet requirements, communication cadences, and decision triggers before a real incident occurs. This is especially important for SaaS-heavy organizations that depend on third parties for identity, data processing, customer operations, finance, HR, logistics, or production workflows.

Security Program and Governance Assessments

MSI can assess whether current policies, vendor-risk processes, incident response plans, contracts, and evidence sources are sufficient to support defensible cyber risk decisions under pressure.

The goal is simple:

When something goes wrong, your organization should not be discovering for the first time that the facts needed for a materiality decision are trapped in a vendor’s system.

Those dependencies should be mapped.

Those expectations should be negotiated.

Those escalation paths should be tested.

Those evidence gaps should be known.

To start a conversation with MicroSolved, Inc., contact MSI at info@microsolved.com or +1.614.351.1237. MSI routes inquiries to the appropriate advisory, governance, assessment, response, or product specialist based on the issue the organization is trying to solve. 

Final Thought

Cyber materiality is no longer only an internal evidence problem.

It is a third-party evidence problem.

That is the next maturity step.

The companies that handle this well will not be the ones with the longest questionnaires or the thickest vendor files. They will be the ones that know which third parties matter to enterprise decision-making, what evidence those third parties must produce, how quickly it must arrive, how confidence will be scored, and what the organization will do when the evidence is missing.

Materiality does not fail only when facts are bad.

It fails when facts are late, unverifiable, incomplete, or trapped in someone else’s system.

Do the hard work now.

Map the evidence dependencies.

Fix the contracts.

Test the vendors.

Rehearse the ambiguity.

Because during an incident, your organization will not rise to the level of its vendor-risk policy.

It will fall to the level of its vendor evidence supply chain.

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:

Continue reading →

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!