Home Blog

CyberSec Delhi Conference 2026

Securing India’s Power, Defence, Manufacturing & Industrial Ecosystems

The CyberSec Delhi Conference 2026 will bring together policymakers, government stakeholders, industry leaders, cybersecurity experts, and technology innovators to address the evolving cyber threat landscape and strengthen India’s cyber resilience. The conference will provide a strategic platform to exchange insights, showcase next-generation security solutions, and develop collaborative approaches to protecting India’s digital and physical infrastructure.

Theme: Securing India’s Power, Defence, Manufacturing & Industrial Ecosystems
Date: 7 October 2026
Time: 8:30 AM – 5:30 PM
Venue: Radisson Blu Plaza Delhi Airport, New Delhi

Key Conference Sessions

  • Opening Address: Securing India’s Critical Infrastructure — The Road to National Cyber Resilience
  • Keynote Address: India’s Critical Infrastructure at the Crossroads of AI, Geopolitics & Hybrid Warfare
  • Panel Discussion: The Resilience Question — How Secure Are India’s Essential Services Against Emerging Cyber Threats?
  • Live Scenario & Incident Post-Mortem: Ransomware Under the Microscope — Anatomy of an Attack on Critical Infrastructure
  • Fireside Chat: The CISO’s DPDP Dilemma — Balancing Data Protection, Cyber Risk & Operational Continuity
  • Panel Discussion: From Substations to Control Rooms — Securing India’s Power Grid Against Cyber Threats
  • Panel Discussion: The Stakes Are Higher — Protecting India’s Defence, PSUs & Strategic Infrastructure from Emerging Cyber Threats
  • Expert Talk: The Next Cyber Battlefield — AI-Powered Attacks on Critical Infrastructure
  • Industry Presentation: Securing the Future of India’s Critical Infrastructure
  • Fireside Chat: From Conversation to Coordination — What Would a Real ‘Cyber Shield’ for India Take?
  • Closing Remarks: From Resilience to Readiness — The Way Forward for India’s Cyber Defence

Who Should Attend?
Government agencies, critical infrastructure operators, defence organisations, utilities and energy companies, transportation authorities, airports and ports, smart city authorities, CISOs, CIOs, CTOs, OT/IT security leaders, and enterprise decision-makers.

With a focused agenda and high-value audience, the conference is designed to create meaningful conversations between cybersecurity technology providers and organisations facing immediate and emerging security priorities.

Delegate Registration: conference.cybersecindiaexpo.com

Sponsorship Enquiries: Tasneem Kanchwala | +91 97407 70166 | [email protected]

Sohail Sayed: +91 86556 57190 | [email protected]

Delegate Enquiries: Aastha Gupta | +91 86556 57159 | [email protected]

SBOM, VEX, and AI: Dr. Allan Friedman on the Future of Software Supply Chain Security

Blockchain security digital technology concept with glowing blue digital chain on dark backdrop. 3D rendering

A conversation on why software transparency is no longer optional, and how AI is about to make it more urgent than ever.

Every piece of software an organization runs today is, in reality, a patchwork: open-source libraries, proprietary code, and third-party components stitched together into a single product. Most buyers never see what’s inside. That blind spot, according to Dr. Allan Friedman, is one of the biggest unaddressed risks in enterprise technology.

Friedman has worked on this problem from inside government, at the U.S. Department of Commerce, CISA, and NTIA, and holds a PhD from Harvard in public policy; he is also a professor at Indiana University. He’s often introduced as the “father of SBOM,” but he’s quick to push back on the label. As he explains it, the idea of a Software Bill of Materials predates his involvement entirely; it was drawn from supply-chain and quality-management practices already common in heavy manufacturing. His actual contribution, he says, was helping carry that idea into policy circles and building a community, spanning hospitals, vendors, and the open-source world, willing to work through it together.

In a recent episode of the cyberc podcast by EC-Council, Friedman walked through the state of the SBOM movement, the rise of its sister concept VEX, and what generative AI means for an industry that has only just started taking supply chain transparency seriously.

What an SBOM Actually Is

Friedman’s explanation leans on a simple analogy: a candy wrapper’s ingredient list. Software, like packaged food, is assembled from many components: open-source libraries, proprietary modules, third-party code. An SBOM is the structured, machine-readable record of everything that went into building it.

That transparency serves multiple purposes at once, he explained. It lets an organization assess whether software carries known vulnerabilities, whether components are approaching end-of-life, and whether a vendor is managing open-source dependencies and licensing responsibly. It also has a quieter cost dimension: technical debt buried in outdated dependencies eventually gets passed on to the customer, whether through breakage, unsupported components, or expensive refactoring down the line.

Operationally, Friedman said, the real payoff is speed. When a new vulnerability breaks, an organization with SBOM data can immediately determine exposure across its software estate rather than scrambling to find out.

The WannaCry Moment That Changed the Conversation

Asked how he got software vendors and enterprises to take SBOM seriously when the concept was, in his words, close to “a career killer” as recently as 2014, Friedman pointed to a story from the WannaCry outbreak. A CISO at a major U.S. hospital had to pull his security team off active work simply to phone medical device manufacturers and ask what operating system their equipment ran on. One Fortune-listed device manufacturer reportedly couldn’t even answer consistently, and the device in question turned out to be running an unpatchable, vulnerable version of Windows.

That kind of incident, Friedman said, is what brought hospitals, critical infrastructure operators, and the open-source community into the same room. The turning point for broader industry buy-in, however, was the SolarWinds attack, even though, as Friedman is quick to point out, an SBOM would not have stopped it. SolarWinds was a compromise of the vendor’s build process, not of a vulnerable third-party component. “The mixing bowl wasn’t clean,” as he put it, a different supply chain problem than SBOM was built to solve. But the attack still shifted SBOM from an obscure corner of cybersecurity into a mainstream policy priority almost overnight.

Where Regulation Actually Stands in 2026

Sixteen years after supply chain risk first became a fixture of U.S. government conversations, Friedman says regulation has arrived, though not always in the clean-cut form it was first proposed.

A 2021 U.S. executive order originally called for an SBOM requirement across software sold to the federal government. By Friedman’s account, the requirement was progressively softened by the time the implementing language was finalized, and what emerged was less direct than the original order intended. Even so, he noted, enough major vendors had already committed to the idea that the effort pushed the industry toward building SBOM-generation capability for newer products.

More consequential, in his view, is the EU’s Cyber Resilience Act (CRA), which applies to digital products sold across the European Union’s 27 member states. Friedman described the CRA as requiring vendors to address a set of security properties, including software updates, coordinated vulnerability disclosure, and enumeration of software components, with an SBOM factoring into that compliance picture. He suggested that companies based outside Europe, particularly those selling IoT products or systems destined for critical infrastructure, are likely to draw early regulatory attention, and cautioned that many businesses aren’t yet aware of what the CRA will require of them.

Outside government mandates, the Payment Card Industry Data Security Standard (PCI DSS) has introduced a requirement that, while it doesn’t use the term “SBOM” directly, obligates organizations to track every software component, including open source, and determine whether it carries a known vulnerability, effectively imposing SBOM-like obligations through a private compliance regime. Japan and South Korea have their own national efforts underway, and Friedman noted that one of his last projects at CISA was a white paper, signed by representatives from 14 countries, affirming SBOM as a shared priority.

Confidentiality, Sharing, and the “1990s Web Portal” Problem

SBOMs are typically shared privately between vendor and customer, not published openly, partly due to intellectual property sensitivities that Friedman doesn’t expect to disappear soon. What frustrates him is how that data still gets shared: largely through static vendor portals, a mechanism he compares unfavorably to nearly every other modern data exchange. He pointed to OWASP’s Transparency Exchange API as an early, still-maturing effort to move SBOM sharing toward standardized, automatable APIs rather than manual portal downloads.

Introducing VEX: Telling Customers What Doesn’t Matter

One of the more practical concepts Friedman has helped develop is VEX, the Vulnerability Exploitability eXchange. Where an SBOM tells a customer that a vulnerable component exists somewhere in a product, VEX lets a vendor formally state that a given vulnerability doesn’t actually affect that product. Friedman’s own example: a product might use an old, flawed version of OpenSSL and still be untouched by Heartbleed, if the vulnerable code path is never exercised.

Friedman’s summary: “SBOM turns on the warning light. VEX lets you turn it off.” He expects VEX to become especially important under the CRA, which imposes tight deadlines for vulnerability response, since VEX data allows that response to be automated rather than manually verified case by case.

AI’s Double Impact on Supply Chain Security

Asked how artificial intelligence complicates the picture, Friedman broke the question into two parts: AI systems as products, and AI as a code-writing tool.

On the first, he described emerging work on what some call an “AI-BOM”: extending the ingredient-list concept to cover an AI system’s software and infrastructure, along with information about the data used to train the model. That matters commercially and geopolitically. Friedman pointed to a Chinese model such as DeepSeek as an example where a lack of transparency could create challenges for organizations trying to sell AI-based products into certain U.S. government or regulated environments, and suggested that tracking training-data provenance could help organizations flag intellectual property or bias concerns before they become liabilities.

On the second, AI-generated code, Friedman raised an open question rather than a settled prediction: will AI coding agents continue pulling in third-party dependencies, or increasingly write more self-contained code from scratch? He suggested either path carries risk worth watching. Coding agents draw on patterns and snippets from public codebases when generating “original” code, which raises the question of whether flawed or insecure patterns could work their way into generated code without ever showing up as a formal, trackable dependency. Friedman framed this as a reason SBOM-style transparency will need to keep evolving alongside how software itself is produced, rather than a settled outcome.

The Trouble With CVEs

Pressed on whether the CVE and vulnerability-database ecosystem is broken, Friedman was candid: there’s tension between adding richer, more detailed vulnerability data and keeping the system accessible enough for small vendors and open-source maintainers to participate. He pointed to a technical shift underway as one sign the system is evolving: for open-source components, package URLs (PURLs) are increasingly being used alongside the older Common Platform Enumeration (CPE) identifiers within CVE records, rather than replacing them outright. He also noted a real gap: CVE records traditionally don’t cover malicious packages, which means organizations tracking npm-style supply chain attacks need to pull from separate threat feeds entirely.

No Architecture Solves Trust Alone

Reflecting on incidents like SolarWinds, Codecov, and 3CX, each of which raised its own questions about software supply-chain trust, Friedman invoked Ken Thompson’s 1974 essay “Reflections on Trusting Trust,” arguing there’s no single point in the software supply chain where absolute trust can be established. Automatic updates remain good security policy on balance, he said, because they force vendors to build more disciplined, stable release processes. But that doesn’t remove the need to understand a vendor’s own upstream exposure, a lesson he says the 2024 CrowdStrike outage, which also disrupted Microsoft-based systems for many organizations, reinforced: your own software can be built well and you can still go down because of something it depends on.

What This Means for the Workforce

Closing on a workforce note, Friedman raised a concern less about tooling and more about people: as coding agents take over the work traditionally done by junior developers, the industry risks losing the pipeline of engineers who learn software by debugging it directly, the people who eventually become the senior engineers capable of deep incident response. He expressed skepticism toward claims that AI will eliminate software vulnerabilities within a couple of years, and argued the enduring value of the security profession isn’t self-perpetuation. It’s protecting the infrastructure everyone depends on. Attack surface management, he suggested, is where the field’s next generation of shared tooling and standards work needs to focus.

This article is based on an interview originally aired on the cyberc podcast by EC-Council, hosted by Jay Bavisi, featuring Dr. Allan Friedman.

Listen on:

Model-Borne Consequence: Why OT Security and Data Security Just Became the Same Job

Sketch confused businessman concept with lot of crazy lines

For thirty years we told you industrial cybersecurity was fundamentally different from IT cybersecurity. We were right. Then AI made us wrong, and it didn’t bother sending a memo.

By Matt Morris, VP of Security & Resilience, EverLine

If I had a dollar for every time I’ve explained to an IT security professional why OT/ICS cybersecurity is different, I could fund a respectable OT security program. Probably with money left over for better coffee in the SOC.

The explanation always went the same way. IT security protects data. When enterprise systems get hit, you lose records, you lose money, you take reputational damage, you have a rough quarter. Serious, and usually recoverable. OT and ICS security protects physical processes. The electricity moving through a substation. The pressure in a distribution main. The temperature in a reactor. When those fail, or when somebody forces them to fail, you’re not talking about a rough quarter.

That distinction was real, and it’s the whole reason this field was hard. OT practitioners were never just cyber people. We were part control engineer, part safety professional, part defender, working in environments where a routine patch could take a process offline and a well intentioned network scan could physically damage equipment. When I described it as the carpeted space versus the uncarpeted space, that wasn’t a rhetorical flourish. It was an accurate description of two worlds that happened to share a few acronyms.

I want to state something plainly, because I haven’t seen anyone put it this directly yet. That distinction is collapsing. AI is doing it. It happened gradually and then quickly, and most of the industry is still building programs, teams and budgets as though the two worlds remain separate.

I call the mechanism Model-Borne Consequence. Physical harm delivered through the data and model layer rather than the control layer. It’s new, it’s measurable, and almost nobody is watching for it.

“Model-Borne Consequence: physical harm delivered through the data and model layer rather than the control layer. The attack surface is data. The outcome is physical.”

How different these worlds actually were

You have to respect how genuinely separate these disciplines were, because those differences still shape how organizations hire, budget and govern today.

Traditional OT was built on three things IT security has never had to accommodate: long lifecycle, operational continuity, and physical consequence. A programmable logic controller is designed to run twenty years or more. Your enterprise endpoint refresh cycle is three to five years, and even that feels slow. PLCs don’t get refreshed. They get calibrated to a specific physical environment and then left alone, because the operational risk of touching them usually exceeds the security risk of not touching them.

The security model that grew out of that reality was physical isolation, network segmentation and operational discipline. The Purdue Model, which every ICS practitioner has effectively memorized, formalized the separation between the process world and the data world.[1] Keep control systems away from enterprise IT. Keep enterprise IT away from the internet. Treat physical access as the primary perimeter.

Stuxnet was the proof that this had limits. Discovered in 2010, it was the first known instance of a digital attack manifesting itself as a physical outcome. It crossed air gaps through USB media, embedded itself in Siemens S7 PLCs at Natanz, and drove centrifuges past their safe rotor speeds while feeding operators falsified all-normal readings.[2] In a dark way it was a masterpiece, because it understood that OT attacks are about physical process manipulation rather than data theft. The weapon was the gap between what the system appeared to be doing and what it was actually doing.

BlackEnergy against the Ukrainian grid in 2015, where attackers harvested credentials, pivoted into SCADA and remotely tripped breakers at more than thirty substations.[3] Triton in 2017, built specifically to defeat safety instrumented systems. PIPEDREAM in 2022, the most capable ICS attack framework ever publicly documented, able to scan for and reprogram controllers from multiple vendors out of the box.[4] Every one of them built on the same insight Stuxnet demonstrated. Attack the physical process, not the data about it.

Data security and process security were different problems. We were right to insist on it.

Then AI showed up in the uncarpeted space

AI has moved from something operators were exploring to something actively embedded in operational environments, usually without a clear decision point and frequently without governance that matches what’s actually happening. Predictive maintenance models forecasting equipment failure. Anomaly detection flagging deviation from normal process behavior. Optimization engines managing energy dispatch, chemical processing and water distribution.

In December 2025, CISA published joint guidance with the NSA, FBI and cyber agencies from Australia, Canada, the UK, Germany, the Netherlands and New Zealand on secure integration of AI in operational technology.[5] The document names a set of OT failure modes that had no place in traditional OT frameworks: model drift, data poisoning, prompt injection and limited explainability. It’s blunt about the stakes, warning that LLM based systems almost certainly should not be used to make safety decisions in OT environments.[5]

Read that list again. Model drift. Data poisoning. Prompt injection.

Those are data security concepts, and they’re now named operational technology risks in joint guidance from nine national cyber authorities. Stated differently, the presence of these vectors are not just a trend. They represent the boundary moving in an official document.

Meanwhile the underlying exposure keeps widening. Forescout logged 508 ICS advisories covering 2,155 vulnerabilities in 2025, the highest volume since tracking began, with 82 percent rated high or critical.[6] SANS found 19 percent of organizations reported at least one OT security incident in a single year.[7] And roughly half of manufacturing leaders surveyed planned to deploy AI or machine learning for cybersecurity within twelve months,[8] which adds fresh model surface to environments still working through OT security fundamentals.

The mechanism, precisely

Precision matters here, because it’s the difference between nodding at an idea and acting on it.

Traditional OT was deterministic. A PLC follows programmed logic. If pressure exceeds threshold, close valve. The security question was whether that logic had been tampered with, which is a process integrity question managed through access control, segmentation and change management. Sensor data fed the logic, but the logic itself was static, auditable, and independent of any ongoing data relationship.

An AI system making operational decisions is architecturally different. Its behavior is a function of training data, model weights and the live data it receives. Compromise the training data and you compromise behavior. Compromise the live sensor feed and you compromise output. Let the model drift as conditions change with nobody watching, and you get a system confidently recommending actions based on a physical reality that no longer exists.

A pipeline running AI anomaly detection on subtly manipulated pressure data will generate wrong alerts, or worse, fail to generate the right ones. A treatment plant whose optimization model was trained on poisoned data will recommend incorrect chemical dosing. A grid operator running AI assisted load balancing through a model that drifted after a generation mix change may push dispatch that works against frequency stability. None of these are hypothetical attack classes; they map directly to documented AI failure modes.[9]

In every one of those, the attack surface is data and the consequence is physical. That’s Model-Borne Consequence, and defending against it requires both disciplines at once, because the system under attack is itself integrated.

The conclusion most people are going to get wrong

Here’s where I expect the market to draw exactly the wrong lesson, and I’d like to get ahead of it.

If OT security now includes data security, the tempting conclusion is that the enterprise IT world has finally absorbed the industrial problem. Bring in the corporate SOC, layer on an AI governance framework, call it solved. I’ve already seen the outline of that pitch forming.

It’s wrong. Convergence didn’t hand the problem to IT. It created a capability gap that most of the market can’t cross from either direction.

The enterprise security world has real competence in model integrity, training data governance and drift detection. It has close to none in physical consequence. It doesn’t know what a twelve percent dosing error does downstream, which failure modes a safety instrumented system was designed to catch, or why isolating the asset is frequently the wrong response in a continuous process.

The traditional OT world understands consequence in its bones and has close to none in model governance. It has never had to reason about training data provenance, because until recently there wasn’t any training data to reason about.

The frameworks themselves tell the story. Current OT threat modeling guidance now recommends pairing MITRE ATT&CK for ICS with MITRE ATLAS, the adversarial AI framework.[5] You need both matrices open on the same desk. That’s the whole argument in one workflow change.

“Convergence didn’t hand the industrial problem to IT. It created a gap most of the market can’t cross from either direction.”

What this actually demands operationally

The useful news is that the required capabilities aren’t exotic. They’re disciplines mature operational security programs already run, extended to a new artifact class. Organizations that recognize this early will find they’re further along than they assumed. The ones treating AI governance as a separate greenfield program will spend more and get less.

Patch management becomes model revalidation. CISA recommends establishing safe operating bounds, monitoring for drift or abnormal behavior, and validating outputs in simulated environments before redeployment.[5] That’s a patch cycle applied to models instead of firmware. Same discipline, same cadence problem, same friction with operations.

Backup and restoration becomes model rollback and deterministic fallback. The guidance is explicit that operators should preserve the ability to revert to manual or deterministic control.[10] Known good model state, tested rollback, and a rehearsed path back to deterministic operation are restoration requirements with continuity attached.

Security operations adds model behavior as a monitored signal. Drift, anomalous inference patterns and poisoned input detection are telemetry problems. A SOC that already correlates operational telemetry against expected process behavior is the right home for them. A SOC that has never seen a process historian is not.

Incident response gets a new opening question. When something goes sideways in an AI influenced environment, the first question is no longer whether you were attacked. It’s whether this was an attack or drift, and how you tell the difference under time pressure with the process still running. Very few IR playbooks answer that today.

Lifecycle services extend to model lifecycle. The joint guidance recommends a secure AI system development lifecycle covering design, procurement, deployment and long term operation, with explicit shared responsibility allocation across owner, vendor and integrator.[10] Somebody has to own the question of who’s accountable when a vendor model behaves unexpectedly inside your process, and that answer needs to exist beforehand.

Compliance gains an entirely new surface. Joint national guidance, EU AI Act enforcement ramping through 2026, and sector specific expectations are all landing on organizations that in many cases haven’t finished their existing OT compliance work.

Why I’m writing this from where I sit

I’ve spent twenty five years arguing that OT security deserves its own seat, its own budget and its own career path. I still believe every word of that. But intellectual honesty means acknowledging when the ground moves.

It moved. AI didn’t ask permission before embedding itself in operational systems, didn’t wait for governance to catch up, and didn’t notify anyone that the separation between data security and process security was going obsolete. That’s just what transformative technology does. It shows up, and then it’s load bearing before anybody voted on it.

I’ve argued for a long time that probability is a guess and consequence is a fact, and that serious operators work the fact. Model drift is probabilistic. What a drifted model does to a physical process is not.

The most dangerous gaps in critical infrastructure are almost never the ones everyone is discussing. They’re the ones that opened while attention was somewhere else. This one opened while the industry watched AI arrive in the carpeted space. It arrived in the uncarpeted space too, and it brought the data security problem with it.

We should probably talk about that.

References

1. Splunk. “OT Security Is Different, Isn’t IT?” Overview of the Purdue Model as the architectural separation between enterprise IT and industrial process layers. splunk.com

2. SIGA OT Solutions. “Revisiting Stuxnet, 15 Years Later.” June 2025. Details on Natanz PLC compromise, malicious ladder logic injection, and falsified sensor reporting. Corroborated by HSToday, “Stuxnet and Beyond: The Origins of SCADA and Vulnerabilities to Critical Infrastructure.”

3. E-ISAC and SANS ICS. “Analysis of the Cyber Attack on the Ukrainian Power Grid.” 2016. Credential harvesting, lateral movement into SCADA, and remote breaker operation across more than thirty substations.

4. Dark Reading. “A Brief History of ICS-Tailored Attacks.” October 2023. Triton/TRISIS safety system targeting; PIPEDREAM native ICS device interaction. Corroborated by CISA advisory on PIPEDREAM/INCONTROLLER.

5. CISA, NSA, FBI, ASD’s ACSC, Canadian Centre for Cyber Security, BSI, NCSC-NL, NCSC-NZ and NCSC-UK. “Principles for the Secure Integration of Artificial Intelligence in Operational Technology.” December 3, 2025. Named OT-specific AI risks including model drift, data poisoning, prompt injection and limited explainability; LLM safety decision warning; recommended pairing of MITRE ATT&CK for ICS with MITRE ATLAS; safe operating bounds and pre-redeployment validation. cisa.gov

6. Forescout Technologies. ICS vulnerability research, 2025. 508 advisories covering 2,155 vulnerabilities, highest volume since tracking began, with 82 percent rated high or critical severity.

7. SANS Institute. “2024 ICS/OT Cybersecurity Report.” 19 percent of surveyed organizations reported one or more security incidents within a single year.

8. Rockwell Automation, via Solutions Review. “AI As a Double-Edged Sword for OT/ICS Cybersecurity.” September 2025. 49 percent of surveyed manufacturing leaders planned AI/ML cybersecurity deployment within twelve months.

9. Documented AI failure modes in operational technology environments, including data poisoning altering safety thresholds, model drift degrading recommendation accuracy as physical conditions change, and model evasion causing malicious commands to appear as normal operational behavior. See ISACA, “AI Security Risk and Best Practices” (2024), and CISA reference 5 above.

10. CISA et al., reference 5 above. Integration challenge mitigations including reversion to manual or deterministic control; secure AI system development lifecycle spanning design, procurement, deployment and long term operations with shared responsibility allocation across owners, vendors and integrators.

Matt Morris
VP of Security & Resilience, EverLine

About the Author

Matt Morris helps Fortune-level enterprises and national security stakeholders govern the physical world as it becomes software-defined. His work focuses on the convergence of cyber-physical systems, AI decision-making, and national-scale resilience — where operational failure has real-world consequences.

Matt Morris operates at the intersection of cyber-physical systems, AI governance, and national-scale infrastructure resilience. Over his career, he has helped shape how Fortune-level enterprises, critical infrastructure operators, and government stakeholders secure and modernize the physical systems that keep societies running.

Matt’s work spans:

  • Cyber-physical systems
  • Operational technology (OT) & industrial control systems (ICS)
  • Autonomous & clinical environments
  • AI-driven digital layers influencing physical safety

Commercial leadership roles have included:

  • Landis+Gyr (smart energy, ami+han, distribution automation, grid & metering)
  • Cisco (Industrial IoT, cyber, digitization, smart cities, and connected healthcare)
  • NexDefense (ICS security)
  • Siemens Energy (digitization and global industrial cybersecurity)
  • Burns & McDonnell (1898 & Co.) — where he built and scaled one of the industry’s largest CPS security consulting practices

    • NATIONAL-SCALE POLICY & STANDARDS ENGAGEMENT

    Parallel to his commercial roles, Matt previously established a partnership with Idaho National Laboratories (INL) where he and his team were instrumental in early-stage development, training, and commercialization of both Cyber-informed Engineering (CIE) and Consequence-Driven Cyber-informed Engineering (CCE).

    Matt also served as President and Board Member of ETHOS, a public–private intelligence and information-sharing partnership supporting critical infrastructure defense. Through this work and broader CPS security initiatives, he has contributed to national security programs for the United States Government (USG).

    Matt has advised:

    • White House Office of the National Cyber Director (ONCD)
    • U.S. Department of Energy (CESER)
    • DHS CISA

    Today, Matt helps leaders navigate three converging shifts:

    • The physical world is becoming software-defined
    • AI is moving into operational decision-making
    • Governance is becoming the bottleneck — and differentiator

    Matt advises leaders on how to build strategies, operating models, and system architectures that survive these shifts—balancing innovation with safety, resilience, and long-term continuity.

    Truth, Transparency, and a Subpoena: Inside TikTok’s Security Crisis with Roland Cloutier

    How the former ByteDance CISO led a 3-billion-user platform through congressional hearings, an international ban threat, and the biggest failure of his career

    There are not many people who can say they have been personally subpoenaed to testify before the U.S. Senate about the security of a platform used by 3 billion people. Roland Cloutier can. As the former Chief Information Security Officer of ByteDance, the company behind TikTok, Cloutier spent years defending one of the most scrutinized platforms in the world, through congressional hearings, international bans, and relentless political pressure.

    In a candid conversation with Jay Bavisi on The Cybersecurity Podcast by EC-Council, Cloutier pulled back the curtain on what it actually takes to lead security at that scale. The conversation ranged from team-building philosophy to the three jobs every CISO now has because of AI, and it closed with a rare admission: his own biggest professional failure.

    From Federal Law Enforcement to the C-Suite

    Cloutier’s path into cybersecurity did not start in a security operations center. He began his career in the military, working for the Department of Defense in aerospace defense as a combat security policeman, before moving into federal law enforcement. It was there, working criminal and civil investigations, that he first encountered the “computer stuff” that would define his career.

    “I couldn’t even spell computer at the time,” Cloutier said. He went back to university, studied computer science, and discovered a passion for technology that pulled him out of federal law enforcement and into the private sector. The switch, he noted with a laugh, also doubled his paycheck.

    What followed was a career built around a simple throughline: stopping bad guys, whether in law enforcement or in the private sector. Along the way, Cloutier developed a reputation for building high-performing security teams, a skill he credits directly to his military background.

    The CISO Mindset: Stop Absorbing the Blame

    CISOs, Cloutier argued, are too often the scapegoats when something goes wrong, and it is a major reason the role has such high turnover. But he believes much of that burden is self-inflicted.

    “People that do this work are passionate. They’re passionate about defending, about doing the right thing, about engaging their business to do it. And oftentimes they blame themselves more than other people blame them.”

    His prescription is a mindset shift: stop trying to be the final decision-maker on business risk. Instead, operate as a business leader who provides transparency, sound advice, and clear options, then lets the business decide. “When we hold the decisions to ourselves, that’s typically when things go wrong,” he said.

    That philosophy extends to how he builds teams. Cloutier described assembling what he calls “command staff,” senior leaders who rotate roles every two to three years so that no single person becomes a point of failure. The goal is a team of well-rounded practitioners who can step into any seat if a colleague is unavailable, creating an organization that can respond quickly no matter where a threat emerges.

    Three Jobs, One Title: The CISO’s New Mandate Under AI

    Much of the conversation centered on artificial intelligence, and Cloutier was direct about how it is reshaping the CISO role. In his view, today’s security leaders now carry three distinct, equally important responsibilities.

    The first is enabling the business to use AI at competitive speed. “The CISO has to be focused and engaged in ensuring the organization can use the technology it is necessary to be successful and win in the market,” he said, adding that this comes before, not instead of, governance and standards.

    The second is defending against AI-powered attacks, a threat Cloutier has watched evolve firsthand. He recalled seeing automated, sub-second attack patterns against platform controls years ago that had nothing to do with a lone attacker at a keyboard. “That’s pure automation against a control you just implemented, and it’s testing its new attack against you,” he said. “That was four years ago. The world has changed.”

    The third job is running the security organization itself like a business. With budgets that can reach tens of millions of dollars and staff levels rivaling a mid-sized company, Cloutier believes CISOs must apply the same AI-driven efficiency gains to their own operations that they expect from the rest of the enterprise.

    A Bold Prediction: Some Security Jobs Will Disappear

    Cloutier does not see AI simply adding tools to the security stack. He predicts it will eliminate entire categories of work while creating new ones.

    “I’m sorry to say it to the GRC and the third-party risk teams, but those jobs are not going to exist.”

    If a system can continuously map data flows, evaluate third-party controls, and deliver active threat intelligence automatically, he argued, the manual version of that work becomes redundant.

    In its place, Cloutier expects a wave of entirely new specializations: certified data science defense specialists, AI pipeline architects, API security engineers, and what he calls AI threat control defense engineers. “There are these big new bubbles of work that are coming up that we don’t have anybody in there,” he said. “If someone wants to be really successful, they start thinking three, five years down and start training themselves for it.”

    His advice to practitioners is to treat this the way the industry treated the shift to cloud computing a decade ago: painful in the transition, but ultimately a net positive for the profession. “I’m actually hopeful,” he said.

    Inside the Subpoena: Truth, Transparency, and a Trusted Team

    No part of the conversation drew more attention than Cloutier’s account of preparing for congressional and Senate testimony during his time at ByteDance. His approach, he said, boils down to four things: truth, transparency, facts, and an amazing team.

    “Proper preparation prevents piss-poor performance.”

    Cloutier described a rigorous preparation process that began with understanding exactly what was being asked, and why. He worked closely with legal teams to anticipate difficult questions and rehearsed with colleagues who could challenge him the way lawmakers would.

    Asked whether he felt attacked during questioning, Cloutier estimated it happened perhaps 20 percent of the time, but said he did not resent it. “They got a job to do,” he said. “If the technology I’m defending is operating within their areas, they have a right to ask me hard questions.”

    His guiding principle for separating legitimate security concerns from geopolitical noise was simple: “Program consistency counts.” A security program grounded in real, ongoing threat understanding, he said, gives a CISO the footing to answer any question, regardless of the politics surrounding it.

    The Personal Cost of a Year Under Scrutiny

    The congressional and Senate hearings Cloutier faced were not a single event but a period lasting roughly a year, layered on top of running a global security organization across dramatically different time zones and cultures.

    The toll was real. Cloutier described losing sleep, working stretches from early morning to late at night, and neglecting his own physical health for months at a time, despite knowing better. “People in these positions don’t think of it as a physically intensive job, but it is,” he said. “You have to be healthy to do this job.”

    He credits keeping his team motivated through a single word: mission. Employees who understand exactly what they are protecting, he said, whether that is millions of small businesses or hundreds of millions of users in a given country, stay engaged even under intense pressure. “Whatever your company is, your people need to know the mission and be able to articulate it,” he said. “You can throw as much money as you want at them. If they’re not into the mission, they’re going to go to the next place.”

    The Failure He Still Thinks About

    Asked directly about the biggest failure of his career, Cloutier did not deflect. He pointed to his early days at ByteDance, which began on April 1, 2020, in the middle of the COVID-19 pandemic.

    Cloutier normally relies on months of in-person time with a new organization, traveling to meet teams and understand a company’s culture before implementing his security playbook. The pandemic made that impossible.

    “My failure is applying a playbook without the level of due diligence and transparency necessary to make the right decisions about the strategic operations you’re developing.”

    It took roughly three years, he said, before he recognized that the approach did not fully fit the company he was building it for.

    A Playbook for the Next Generation of CISOs

    Cloutier’s story is, in many ways, a preview of what is coming for the entire profession. AI is compressing timelines, automating entire job categories, and raising the stakes for every enterprise CISO. At the same time, the fundamentals he leans on, transparency, consistency, trusted teams, and a clear sense of mission, remain unchanged.

    For CISOs, board members, and risk leaders navigating an increasingly public and increasingly automated threat landscape, Cloutier’s central message is straightforward: the tools will keep changing, but the discipline of truth and preparation will not.

    This article is based on Episode 15 of The Cybersecurity Podcast by EC-Council, featuring host Jay Bavisi in conversation with Roland Cloutier, former CISO of ByteDance (TikTok).

    Roland Cloutier
    (fmr) Global Chief Security Officer TikTok & ByteDance, ADP, EMC. Partner / Principal – The Business Protection Group LLC . Advisor / Board Member / Global Speaker / Author

    About the Author

    Global Executive Security, Risk, and Privacy Leader, Strategic Security Visionary, Author, and Board Member. Focused in Critical Infrastructure Cyber and Kinetic Defensive Operations. Expertise in the management of strategic converged security programs and services and the development of global business operations protection programs.

    New Hampshire–born security leader, military veteran, and digital business enabler with more than three decades of experience protecting global enterprises, critical infrastructure, and fast-moving digital platforms. I have dedicated my career to building and scaling world-class security, risk, privacy, and operational resilience programs across the military, government, and commercial sectors.

    My professional journey began in the United States Air Force at age 17, where I served as a Combat Security Policeman specializing in aerospace defense, anti-terrorism operations, and global en-route protection missions. Following my military service, I continued serving at the U.S. Department of Defense Police and later as a Detective with the U.S. Department of Veterans Affairs Police, conducting major criminal investigations and supporting national security events, including explosive-detection operations during the 1996 Olympic Games.

    Transitioning to the private sector, I spent two decades leading cybersecurity, trust, and risk operations for some of the world’s most influential technology, media, and financial companies. As Global Chief Security Officer for TikTok & ByteDance, ADP, and EMC, I built, scaled, and operated converged global security organizations responsible for cyber defense, privacy enforcement, operational risk, global investigations, crisis response, and workforce protection across more than a dozen countries.

    Today, I serve as Founder & Partner of The Business Protection Group (TBPG), advising multinational corporations, boards, and government entities on cybersecurity strategy, digital trust, operational resilience, and executive-level risk governance. My work focuses on enabling business growth while protecting mission-critical assets, platforms, and operations.

    I am honored to contribute to the cybersecurity community as a board or advisory board member for organizations including Cranium AI, Commvault, RegScale, the Blue Cross Blue Shield Association (Cyber Subcommittee), and others.

    I am also the author of ‘Becoming a Global Chief Security Executive Officer’ (Butterworth-Heinemann), a widely referenced guide for next-generation cyber and security leaders.

    5th Edition MENA CYBER SECURITY CONFERENCE – RIYADH EDITION

    Name: 5th Edition MENA CYBER SECURITY CONFERENCE – RIYADH EDITION
    Website: https://mena-cybersecurity.com/riyadh/
    Date: September 8th, 2026
    Location: Crowne Plaza Riyadh Palace, Riyadh, Saudi Arabia

    6th Edition MENA CISO Summit 2026 – Dubai Edition

    The 6th Edition MENA CISO Summit 2026 is an exclusive one-day leadership platform designed for CISOs, cybersecurity executives, and strategic decision-makers navigating an evolving landscape of complex digital risks. As AI-driven attacks, critical infrastructure threats, and regional compliance demands continue to accelerate, the summit equips senior leaders with the insights needed to strengthen enterprise resilience and advance security maturity across their organisations.
    Featuring high-level keynote sessions, executive panel discussions, and closed-door leadership dialogues, the summit will explore critical topics including threat intelligence, risk governance, cloud and identity security, incident response, and the strategic integration of AI for cyber defence. Each session offers actionable guidance to help cybersecurity leaders enhance visibility, improve agility, and prepare for the next generation of cyber challenges.
    Bringing together senior professionals from Government, BFSI, Oil & Energy, Aviation, Healthcare, Manufacturing, Telecom, and other mission-critical sectors, the summit serves as a hub for high-value networking, collaboration, and knowledge exchange. Attendees will leave with strategic insights, stronger industry alliances, and a practical roadmap for protecting their organisations in an era defined by intelligent, adaptive, and persistent cyber threats.

    Official Website:
    https://mena-cybersecurity.com/ciso-dubai/

    Delegate Registration:
    https://mena-cybersecurity.com/ciso-dubai/attend-as-delegate/

    Promo Code: MENACS05

    Cyber Security Expo

    Name: Cyber Security EXPO
    Website: https://www.cybersecurityexpo.co.uk/cheltenham
    Date: September 10, 2026
    Location: Cheltenham Racecourse, United Kingdom

    The Cyber Security EXPO is the only dedicated recruitment event for Cyber Security Professionals.

    Cheltenham is synonymous with the intelligence community and is an obvious choice for our EXPO, with Cheltenham Racecourse being a perfect venue.

    The varied work created from Cheltenham and the companies that feed into the intelligence network are far reaching, which means cyber skills and UK Security Clearances are in high demand. If you are looking to engage with these niche opportunities that are often not available online, then our Cheltenham EXPO should not be missed!

    Visitor passes are FREE and provide access to all co-located events.

    Register Now

    6th Edition MENA CISO SUMMIT – Dubai Edition

    Name: 6th Edition MENA CISO Summit – Dubai Edition
    Website: https://mena-cybersecurity.com/ciso-dubai/
    Date: September 30, 2026
    Location: Millennium Airport Hotel, Dubai, UAEThe

    6th Edition MENA CISO Summit 2026 – Dubai Edition

    The 6th Edition MENA CISO Summit 2026 is an exclusive one-day leadership forum that brings together Chief Information Security Officers (CISOs), cybersecurity executives, and senior decision-makers to address today’s rapidly evolvingcyber threat landscape. As AI-powered attacks, critical infrastructure risks, and regulatory challenges continue to grow, the summit provides practical strategies and
    executive insights to help organizations strengthen cyber resilience and security governance. The event features keynote presentations, expert panel discussions, and executive leadership sessions covering key topics such as threat intelligence, risk management, cloud security, identity and access management, incident response, cyber resilience, and the responsible adoption of AI in cybersecurity. Attendees will gain actionable knowledge and real-world best practices to enhance their organizations’ security posture and prepare for emerging cyber threats.Bringing together leaders from Government, BFSI, Oil & Energy, Aviation, Healthcare, Manufacturing, Telecommunications, and other critical industries, the summit offers valuable opportunities for networking, collaboration, and knowledge sharing with regional and global cybersecurity experts.

    Official Website:
    https://mena-cybersecurity.com/ciso-dubai/

    Delegate Registration:
    https://mena-cybersecurity.com/ciso-dubai/attend-as-delegate/

    Promo Code: MENACS05

    Build the Pipeline, Not the Headcount

    There’s a principle in Taoist philosophy called wu wei, often translated as “effortless action” or “non-doing.” It doesn’t mean passivity. It means acting in accordance with the natural shape of a system rather than fighting it, adding force only where force is actually needed. Marcus Aurelius wrote something adjacent to this in his own register: focus your energy on what is within your control, and let go of the rest with discipline rather than anxiety.

    I think about both of these ideas constantly when I think about SecOps team structure, because the instinct in our industry runs in exactly the opposite direction. The default response to “we need better security operations” is to add headcount, add tools, add process. More analysts. More dashboards. More meetings to review the dashboards. We mistake motion for progress and accumulation for maturity.

    After spending the better part of fifteen years building and rebuilding a security operations function, first as a practitioner in the trenches, later as the person responsible for the architecture and the people, I’ve come to believe the opposite is usually true. A lean SecOps team, deliberately shaped, outperforms a large one assembled by accretion. Not because lean is cheaper, though it often is. Because lean forces clarity that scale lets you avoid.

    The Crown Jewels Problem

    Every SecOps program eventually runs into the same wall: you cannot monitor everything equally, and pretending you can is how you end up monitoring nothing well. The instinct to treat all assets as equally critical is, ironically, a failure of discipline dressed up as thoroughness.

    The Stoics had a name for the discipline of differentiating what truly matters from what merely demands attention. In practice, this means doing the unglamorous work of tiering your environment, identifying the handful of systems, data stores, and identity paths where a compromise is existential, and being honest that everything else is a lower tier of concern, however uncomfortable that hierarchy feels to the teams who own the lower-tier systems.

    A lean team that has done this work well will outperform a large team that hasn’t, every time, because the lean team knows where to look first. I’ve watched well-resourced programs drown in alert volume from systems that, even fully compromised, wouldn’t materially harm the business, while the genuinely critical paths get the same cursory glance as everything else. In one environment I inherited, well over half of the daily alert volume was coming from a handful of systems that, even fully compromised, would have cost an afternoon of cleanup, while the identity path that actually controlled everything downstream generated a fraction of that traffic and got a fraction of the attention. That’s not a tooling problem. That’s a tiering problem, and no amount of headcount fixes it.

    Relocate the Effort, Don’t Remove It

    If I had to name the single highest-leverage decision in standing up a lean SecOps function, it’s this: invest disproportionately in the pipeline before you invest in people to staff it.

    By pipeline, I mean the actual mechanical flow from signal to action, telemetry ingestion, detection logic, enrichment, case creation, ticketing, and closure, built so that the analyst’s job starts at “here is a contextualized issue requiring judgment” rather than “go figure out if this raw event means anything.” Most SecOps teams I’ve seen are oversized because the pipeline is undersized. The analysts are doing the triage work that automation should be doing, and the organization responds by hiring more analysts to absorb the load rather than fixing the load.

    This is wu wei in its most literal operational sense: you are not removing effort from the system, you are relocating it to where it belongs. The effort of triage, correlation, and initial enrichment belongs in the pipeline, built once and running continuously, not repeated manually by every analyst on every shift. When the pipeline is doing its job, a smaller team can carry a larger surface area, because they are spending their attention on the judgment calls that actually require a human, not on the mechanical sorting that doesn’t.

    What has changed in the last couple of years is how much of that pipeline can now run itself. Autonomous investigation has become good enough to handle first-pass triage, correlation, and enrichment at a speed and volume no human shift can match. I’ve stopped treating that as a threat to the team and started treating it as the pipeline finally doing what it was always meant to do. But there is a line I draw deliberately, and every security leader should draw it consciously rather than by default: a named person validates every high-impact action before it executes. Machine-speed autonomy earns its keep during investigation. It turns dangerous the moment it reaches an action with real consequences. The structural question is no longer whether to let the system act, it’s deciding precisely which actions a human must still own, and making sure that person carries the context to own them well. Agentic operations that no one is accountable for are not efficient, they are unmanaged risk with a faster clock. This is also where the harder cost of automation shows up, not in what it removes from today’s workload, but in the analysts it quietly stops training.

    This is also, where most of the real engineering investment in a lean SecOps function should go. Not in adding another seat. In tightening the path between signal and decision until very little human attention is wasted on noise.

    The Generalist Bench, Not the Specialist Roster

    Lean teams cannot afford deep specialization the way large SOCs can, and I’ve stopped treating this as a constraint to apologize for. It’s a design feature.

    A team of generalists who each carry breadth across detection, response, and a working knowledge of the underlying infrastructure is more resilient than a team of narrow specialists, because a lean team has no redundancy to spare. If your cloud security specialist is the only person who understands the cloud security tooling, you do not have a lean team, you have a single point of failure wearing a job title. The Stoic emphasis on self-sufficiency applies at the team level just as much as the individual level: a team that depends on one irreplaceable expert has built fragility into its own structure, however capable that expert is.

    This means hiring and developing differently than a large SOC would. You are not looking for the deepest possible expertise in one narrow domain. You are looking for people with genuine intellectual curiosity and the discipline to go deep when a specific incident demands it, then come back up to breadth. I have had far more success developing this kind of analyst by deliberately handing direct reports problems slightly outside their comfort zone, under supervision, with the safety net intact, than by hiring someone whose resume already claims the expertise. Developed breadth, in my experience, holds up better under pressure than purchased depth.

    There is a harder version of this problem coming, and it is worth naming plainly. Tier 1 triage has always been how people entered this field. You learned the trade by working the queue. As that work moves into the pipeline, the traditional on-ramp thins. If the machine handles the reps that used to season a junior analyst, judgment will no longer accrue as a byproduct of volume, and we have to develop it on purpose. For a lean team this is close to existential, because you cannot buy senior judgment at the scale a large SOC can. You have to grow it. On my own team we’ve baked this into how we run. Junior hires get scheduled stretch assignments during onboarding, and senior staff have protected teaching time instead of squeezing it in around the job. Development has to be treated as core infrastructure rather than a perk.

    What You Let Go Of

    The hardest part of running a lean team isn’t building it. It’s the ongoing discipline of not letting it become a large team by a thousand small additions: one more tool here because a vendor made a compelling pitch, one more process step there because an audit finding demanded a control nobody fully thought through, one more headcount request because last quarter was busy.

    Each addition, in isolation, looks justified. The damage is cumulative and structural: every tool is something the team must maintain attention on, every process step is friction in the pipeline, every uncoordinated hire is one more person who needs onboarding into context the rest of the team already shares. A lean team stays lean only through active maintenance, the same way a disciplined mind stays disciplined only through ongoing practice rather than a single decision made once.

    I’d rather say no to a tool that does something marginally useful than say yes and watch the team’s attention fragment another few percentage points. Attention, more than headcount or budget or tooling spend, is the real scarce resource in security operations. Every addition to the system draws it down, whether or not it shows up on a budget line.

    Running lean comes down to the harder work: deciding, with discipline and some discomfort, what not to do, and holding that line long after the decision is made. That is the part no tool and no new hire can do for you. The work is knowing what is yours to control, giving that your full attention, and having the discipline to let the rest go.

    Thomas M. Allen

    About the Author

    Thomas M. Allen, Chief Information Security Officer & Chief Privacy Officer at Foresite with over 25 years of experience in cybersecurity, risk management, and regulatory compliance across multiple industries.

    Extensive expertise in PCI-DSS, HIPAA, state data privacy laws, and multiple security frameworks, with deep technical knowledge spanning network security, penetration testing, ethical hacking, cloud security, and secure architecture design and implementation. Foresite is a Google Cloud Premier MSSP and Google Cloud Security Partner of the Year 2026 (North America).

    Smart, Secure & Sustainable: MIFF 2026 Leads Industrial Transformation

    Name : MIFF 2026 (MENA Industrial Futures Forum)

    Smart, Secure & Sustainable: MIFF 2026 Leads Industrial Transformation

    The MENA Industrial Futures Forum MIFF 2026, organized by Dez10 Events, is a premier platform bringing together global industry leaders, innovators, regulators, cybersecurity experts, and technology providers to shape the future of smart, secure, and sustainable industrial operations. Scheduled for 06–07 October 2026 at Grand Hyatt Al Khobar, Kingdom of Saudi Arabia, MIFF will focus on accelerating digital transformation across oil & gas, energy, utilities, petrochemicals, manufacturing, and heavy industries.

    Aligned with Saudi Vision 2030, MIFF 2026 will spotlight critical themes including Industrial Cybersecurity, AI-driven operations, Process Automation, Digital Infrastructure, Sustainability, Semiconductor technologies, Smart Manufacturing, Industrial IoT, and next-generation industrial innovation.

    Register Today: [email protected] & for more details visit mifforum.com

    The forum will feature expert-led conferences, operator-driven case studies, technology showcases, and strategic networking opportunities with senior decision-makers and industry experts from across the Middle East and beyond.

    With participation from leading enterprises, government authorities, and technology pioneers, MIFF aims to drive industrial digitalization, operational resilience, sustainable growth, and cross-sector collaboration while fostering innovation and investment across critical industrial sectors.

    2nd NACSA Cyber Security Summit (NCSS) 2026

    The National Cyber Security Summit 2026 (NCSS 2026) is set to return as a strategic national platform that brings together government leaders, policymakers, industry experts, cybersecurity professionals, technology providers, and key stakeholders from across critical sectors. Taking place from 7 to 9 July 2026 at the Putrajaya International Convention Centre (PICC), Putrajaya, NCSS 2026 will serve as an important avenue to strengthen Malaysia’s cyber resilience and readiness in facing today’s evolving digital threats.

    Hosted by the National Cyber Security Agency (NACSA), National Security Council (NSC), and organised by Alpine Integrated Solution Sdn. Bhd., NCSS 2026 will feature high-level conferences, expert discussions, technical sessions, closed-door workshops, exhibitions, and networking opportunities. The summit will highlight key topics surrounding cybersecurity governance, digital trust, artificial intelligence, critical information infrastructure protection, cybercrime prevention, emerging technologies, and regional cooperation.

    NCSS 2026 aims to encourage stronger collaboration between the public and private sectors while promoting knowledge sharing, innovation, and strategic partnerships. As cyber threats continue to grow in complexity, the summit provides a timely platform for stakeholders to exchange insights, showcase solutions, and build a more secure and resilient digital future for Malaysia and the region.

    123...409Page 1 of 409